Slim 4.0 Road Map

[codeguy]

Here are some intiial thoughts:

• [BC break] Extract Slim\Http into separate PSR-7 component (ONLY PSR-7 methods)
• [BC break] Create custom decorator classes to hold Slim-specific additions to PSR-7
• Accommodate additional media type parsers in request
• Address issues reported by Phan
• Improve test coverage

Additional ideas:

• [BC break] Remove Request, Response and Env from container (@akrabat)
• [BC break] Don't set content-length by default. Provide a middleware for people to use if they want to. (@akrabat)
• Make it faster (or at least don't slow it down!) (@Cyrille37)
• [BC break] Removing Method-Override and providing a middleware (@geggleto)
• [BC break] Decide if we need subRequest at all (@codeguy/@silentworks/@geggleto)
• Lazy resolve route middlewares (#1635) We already do this with route callable(only resolve the matched one). (@mathmarques)
• Look at __invoke and run on App and see if we can consolidate functionality and make them easier to unit test. (@geggleto)
• [BC break] Consolidate error handlers for exceptions and PHP 7 errors (@akrabat)
• Can we avoid statics in Slim\Http? See #1850 (@Raistlfiren)
• [BC break] Look at pathFor()'s parameters? see #1800 (@akrabat)
• [BC break] Do something about basePath from Request. Maybe middleware solution instead? (@akrabat)
• [BC break] Remove determineRouteBeforeDispatch and make routing a middleware that can be placed where you want it to be. If you don't add it yourself, we would add it immediately before dispatch. (@akrabat)
• Use getallheaders() to get the Authorisation header. (irc channel)
• Move documentation into main repo and publish to website on each new release. That way we can insist on documentation with the PR.
• [BC break] Either rename Slim\Exception\SlimException or remove it.

Please add additional thoughts below.

[jeremygiberson]

I'd like to see something like a ModelResponseInterface with the following definition:

interface ModelResponseInterface {
    /**
     * @return mixed
    */
    public function getModel();
}

Right now because the framework requires a Response to be returned from middleware it makes it difficult to do things like writing content-type middlewares that marshal models into json/xml/etc. Officially supporting a response type that provides a container to pass models/objects back to middlewares for processing would be really nice. This could be it's own package too. I just think there should be recommended package at least. That way we will hopefully start seeing HAL rendering middlewares and similar things pop up.

[Cyrille37]

Please, for the Slim roadmap, keep the velocity in priority one. It exists several really greats light frameworks like Lumen and Silex. In my mean Slim is the fastest and should keep the lead.
If one like Lumen or Silex is light and fast as Slim, it will be easier to use them because switching between larger (Laravel, Symfony) will be natural.
Cheers

[geggleto]

@codeguy @akrabat @silentworks ... we should look at Groups again.

[lalop]

With route in a separate middleware and http's classes in a separate repository it seems that Slim's core will not have anything to do with http.
It could be good to define the issue this library want to solve.
it will look like a middleware stack with a container.
On my point of view it could manage any kind of request with the appropriate trinity request/response/router ( http, cli, ... )

[danielgsims]

Remove the VERSION constant from App? It's fallen behind. See #1886

[mathmarques]

What about a setting to change the middleware stack(execution) order?
We use the "Last In First Executed" by default, but we could add a setting to change this behaviour to "First In First Executed" like others frameworks.

[llvdl]

Either document slim.files option for Route::createFromEnvironment and add tests or remove the Environment argument and rename the function to Route::createFromGlobals [BC break] (see #1899)

[marcelbonnet]

Hi, suggestion: allow us to set our own \Slim\Route impl . See #1906 . By now (3.4.2), it is possible, but at risk to break something (since we need to alter part of the Slim\Router::map function to point to our own Route impl)

[geggleto]

Better documentation of internals, notably describing the call-stack for an execution of a route action.

[jaapverloop]

Make it possible to initialize the error handlers with an optional PSR 3 logger. The current situation forces you to extend the error handlers to work around the error_log function.

[kwhat]

I would like to see subRequest or at least some way to check a uri for a route match and then dispatch that request though the router.

[geggleto]

@kwhat I am thinking about dropping subRequest entirely for 4.0 ...

[kwhat]

@geggleto I dug through the router code (Slim + FastRoute) and it looks like subRequest can be completely replaced in my use case. +1 for deleting it and also +1 for removing SlimException ;)

[nickdnk]

Fix error 500 bubble to top on when using unsupported HTTP method https://github.com/slimphp/Slim/issues/2005

[chadicus]

Move documentation into main repo and publish to website on each new release. That way we can insist on documentation with the PR.

Recommend adding PHPDoc requirements to the coding standard for this. It would make it much more enforceable.

[Cyrille37]

Try to have a look to for a performance tool in quality build chain, like https://blackfire.io or other.

[akrabat]

@Cyrille37 Could you expand some more on wha you mean please?

[akrabat]

Move error handling out of core and into middleware?

[geggleto]

@akrabat 👍 What about exceptions though... are we catching Exceptions in an application middleware? If so are we adding it by default but allowing users to remove it?

[akrabat]

@akrabat 👍 What about exceptions though... are we catching Exceptions in an application middleware? If so are we adding it by default but allowing users to remove it?

Not sure yet. Gut feeling is to provide Middleware\ErrorHandling, but not add it by default, so the migration docs would say:

"Add $app->add('Slim\Middleware\ErrorHandling'); immediately after $app = new Slim\App()"

or something.

This would mean that out of the box, PHP's stock error handling would happen which would definitely fit the principle of least surprise.

[geggleto]

My only problem is that there's no way to check in the App and provide users a notification about it. It could technically silently fail which is bad.

[akrabat]

Support http-interop (PSR-15). This will change the signature of middleware to:

function (RequestInterface $request, DelegateInterface $next);

Hence add() will change to support callables of the format:

$app->add(function($request, $next) {} ):

Which means we need to support the current middleware format.

There are two choices:

$app->add(new DoublePassWrapper(function($request, $response, $next) {} )):

or:

$app->addDoublePassMiddleware(function($request, $response, $next) {} ):

i.e. we either wrap the middleware before calling add or provide a new method for middleware of this format.

[codeguy]

Thanks for all the great feedback. I'll organize these thoughts over the weekend and get them added to our issue tracker.

[akrabat]

Need route strategies to be per-route-callable so we have a migration path.

[geggleto]

@codeguy we have an issue tracker? 👍

[tuupola]

FWIW personally I like the wrapper approach.

$app->add(new DoublePassWrapper(function($request, $response, $next) {} )):

[dopesong]

+1 for DoublePassWrapper

[SergeAx]

Just a thought: Is it possible to distinct middleware type by it's signature and implement some kind of autowiring to preserve compatibility?

[mhndev]

It would be great If we could run the whole application through cli .
In my opinion application is separate from how it is going to be called.
In most cases the initiator is a http request from a web server, but each action and each route should be callable though cli commands.
so I think actions shouldn't receive Http Request and Http Response as argument at all.

[odan]

It would like to define Controller actions like a native callable. This would make the action methods compatible with the PhpStorm refactor functionality.

Example

$app->get('/user', \App\Controller\UserController::class . ':indexAction');

Instead I would like to define a route like this:

$app->get('/user', ['App\Controller\UserController', 'indexAction']);

[silentworks]

@odan I don't think there is currently anything stopping you from doing this.

[odan]

@silentworks Ah ok, I saw this feature in PHI-DI and thought it would be nice to have it directly in Slim 4 (only in the context of routes).

Additionally you can call:

• name of invokable classes: $container->call('My\CallableClass')
• object methods (give the class name, not an object): $container->call(['MyClass', 'someMethod'])

In both case, 'My\CallableClass' and 'MyClass' will be resolved by the container using $container->get().

But anyway, this special kind of callable (non-static method as callable) has been deprecated since PHP 7 https://3v4l.org/ORMQ3. My question can therefore be considered as closed. Thanks :-)

[michaeldnelson]

Some of these things might just be middleware or documentation opportunities. I also agree with one of the previous posters that slims "Unique selling proposal" is performance and minimalism so take all of this with a grain of salt.

• Access to subdomain patterns in routing. e.g. {workspace}.myproject.com
• Route binding, I end up writing a lot of boiler plate to get objects/variables from routes, php-di-slim bridge does some things here, would like something like laravel explicit route model binding which should be model/orm agnostic
• I would to add data to a route that can be accessed in middleware, for example, $route->addData(["required_scopes" => ["user"], "name" => "myroute"], then you could write middleware that uses scopes for auth or checks against the name for something.
• Document an example or recommended async pattern for slim. Async is just not optional anymore, it can definitely tip the scales in a framework decision if one framework has robust documented async pattern and another does not.

[ndobromirov]

A big :+1: on the last point from @michaeldnelson.

[zhiyuan-lin]

Any plan to bump the minimal PHP version to 7.x+ and add scalar type hinting for everything?
5.6 should reach EOL when Slim 4 been released.

[danopz]

@edsgerlin #2421

[MarcHagen]

@edsgerlin @danopz #2175

[thangl3]

What time is the Slim 4.x release? I hope it soon.

[ndobromirov]

@mhndev this is where you should use something like https://github.com/php-pm/php-pm/blob/master/bin/ppm and your Slim app works with PSR messages.

[sinitsa]

native domains and subdomains patterns in routing with easy caching would be nice i think..
thanks for your work guys)

[filips123]

When will stable Slim 4.x be released?

[akrabat]

When will stable Slim 4.x be released?

We do not have a date.

[l0gicgate]

Public Announcement
All of the roadmap has been implemented. I feel like we are in a good place to do some alpha testing so we can get some feedback for a beta release.

Before doing anything read the docs
I just finished the first draft of the docs for Slim 4 which are available here. I need feedback please:
http://slim-website.lgse.com

Download an test the 4.x Branch
You may also play around with the 4.x branch and create a simple app with it to test things out.
composer require slim/slim:4.x-dev

Install a PSR-7 Implementation
You will also need to install a PSR-7 implementation and ServerRequestCreator combo. You can use Slim's PSR-7 Implementation or choose one of the ones described on the 4.x branch README: https://github.com/slimphp/Slim/blob/4.x/README.md
composer slim/psr-7:dev-master

Slim 4 DDD API Skeleton Prototype
I also just created a Slim4 Skeleton with a DDD style directory structure and example files and test coverage for everything. I'm not sure if it's the right fit yet as it may be a bit too opinionated but I'd love some feedback:
https://github.com/l0gicgate/Slim-Skeleton/tree/4.x

If you have any questions don't hesitate to ping me, I'm available to help!