We are delighted to release the first stable version of Slim 3, 3.0.0 following a series of release candidates.
Slim 3 is a major update with all parts of the framework updated. These are the highlights.
\Slim\App class composes a dependency injection container that implements container-interop. We ship Pimple by default, but it is possible to swap this out for your own preferred DI container as we support Container Interoperability interface. The DI container means that we can easily inject third-party components into a Slim application or override Slim’s internal objects such as the request and response objects.
Slim’s HTTP request and response abstractions support PSR-7. This means their interfaces differ significantly from previous releases. In the past, each Slim application had one request object and one response object that were passed by reference throughout the entire application.
Version 3, however, treats the request and response objects as value objects. Each middleware layer and application route will receive the most current request and response objects as arguments. Each middleware layer and route callback is responsible for returning an updated HTTP response object.
The HTTP request and response objects are immutable, too. You must use the appropriate
withBody(), etc. request and response object methods to create and return a new request or response object with the specified changes. You can read more about the new interface in the PSR-7 documentation at https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-7-http-message.md.
This also makes it possible to use third-party middleware with the Slim Framework. For example, perhaps you find PSR-7 middleware designed for another framework. However, by virtue of using PSR-7 interfaces, that middleware is also compatible with Slim.
Slim’s PSR-7 changes may sound complicated, but they’re actually pretty simple. You can read more about PSR-7 at:
Coded to an interface
The 3.0 release is (mostly) coded such that all internal app methods expect interfaces instead of concrete class implementations. This means it will be easy to provide your own implementation for any of a Slim app’s dependencies if you want, and you can inject or override dependencies with DI container services.
Route callback binding
If you use Closures as Route callback routines, the Closures will become bound to the Container instance. This means you will have access to the DI container instance inside of the Closure via the
The framework codebase is much simpler. Previously, the application class contained many methods concerning rendering or response headers. This is no longer the case as they have been migrated into other appropriate classes. For example, the
status() methods are removed, and you must use the response object’s methods to modify the HTTP response. Slim no longer ships with view or logger objects allowing you to pick the best components for your needs. We do, of course, continue to provide integration with the Twig templating component via Twig-View and also have PHP view script integtation via PHP-View.
Full documentation is also available.
This release would not have been possible without the support from our community in testing Slim 3 and providing valuable feedback. Thank you!