Slim 4 Release Feedback

[l0gicgate]

Slim 4 Release
See the full release notes.

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:
https://www.slimframework.com/docs/v4

Download the 4.0.0 release
composer require slim/slim:^4.0

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 require slim/psr7

You can also use the Slim 4 DDD API Skeleton to create a new project
composer create-project slim/slim-skeleton [my-app-name]

If you have any questions don't hesitate to ping me on Slack or ask questions in this thread directly, I'm available to help!

[mosfetish]

V3 Docs have a "First Application" item. Be good to see that for v4. Seems pretty essential to me. I note the "DDD Skeleton" above but an app setup guide is what I'm after.

[Hill-98]

I found that the middleware in Slim 4 can't call the dependency container using $this as before, now he will throw an error: Using $this when not in object context, can you tell me how to fix it?

[mnapoli]

Hey! Since this is a feedback thread, here is my feedback ^^

On the home page (here https://www.slimframework.com/docs/v4/) there is an example application that is different from the one showed in "Installation" (here https://www.slimframework.com/docs/v4/start/installation.html). The one on the home page worries me a bit: why is there a thing about adding a routing and error middleware? Does this not work by default? (I hope it does, TBH I'm just out of bed and haven't read the whole docs)

To be honest I don't really care about the PSR-7 implementation and having to choose one and install it is a bit of a pain IMO. I understand decoupling from anything that impacts the user (e.g. the container), but I don't understand why decouple from internal dependencies (PSR-7 and the factories, even routing).

In the meantime I discovered the https://github.com/slimphp/Slim-Skeleton repository, and also discovered it is using PHP-DI (cooool!). I have a few comments there on how it is used and how it could be improved, should I post this here or there?

[l0gicgate]

@Hill-98 showing example code would be great. It sounds like you're trying to call $this from a static context.

[l0gicgate]

@mnapoli

On the home page (here https://www.slimframework.com/docs/v4/) there is an example application that is different from the one showed in "Installation" (here https://www.slimframework.com/docs/v4/start/installation.html). The one on the home page worries me a bit: why is there a thing about adding a routing and error middleware? Does this not work by default? (I hope it does, TBH I'm just out of bed and haven't read the whole docs)

RoutingMiddleware is added by default when a user does not manually add it. This is so you can control when routing is being performed. In Slim 3 we had the setting determineRouteBeforeAppMiddleware which dictated when the routing was being done. Now you can precisely decide when it is being done by changing it's order in the middleware queue.

As for ErrorMiddleware, it needs to be added manually since you would want it to be last in the queue (Last In First Out) of middleware so it catches all of the errors from within the middleware pipeline. In Slim 3 we had a lot of feedback on how tightly coupled error handling was to the core of the App component and it generated a lot of issues, hence why it has been extracted from core and now users have more control over it.

To be honest I don't really care about the PSR-7 implementation and having to choose one and install it is a bit of a pain IMO. I understand decoupling from anything that impacts the user (e.g. the container), but I don't understand why decouple from internal dependencies (PSR-7 and the factories, even routing).

As explained in the release notes, modularity was the primary focus for this release so we can give back more control to the end user and let them make their own design decisions, giving more flexibility as to what core components you want to use and enable you to drop in your own easily if need be.

While you may not want to choose your own PSR-7/Container implementation, I think that the additional flexibility is more important. This is why we have the Slim-Skeleton project, you're also more than welcome to create your own skeleton so other users can benefit from your library choices over ours.

In the meantime I discovered the https://github.com/slimphp/Slim-Skeleton repository, and also discovered it is using PHP-DI (cooool!). I have a few comments there on how it is used and how it could be improved, should I post this here or there?

I would suggest creating an issue over there, since we want to keep things as topical as possible

Did you guys change literally everything?? It's impossible to upgrade from a reasonably sized Slim3 app to 4.

[l0gicgate]

@Rutmeister in order to get Slim in a good spot for the future, we had to break a lot of things unfortunately. Obviously it’s going to be a lot of work to upgrade on a large project, I’m not sure I would recommend doing so.

[Hill-98]

@l0gicgate This is my code:

Slim 3:
I use the container provided by Slim and he works very well.

$app = new App();
$container = $app->getContainer();
$container["cache"] = function () {
    $redis = new Redis();
    $redis->pconnect(REDIS_HOST, 6379, 3, REDIS_PREFIX);
    $redis->setOption(REDIS::OPT_PREFIX, REDIS_PREFIX);
    return $redis;
};
$app->add(function (Request $request, Response $response, $next) {
    $cache = $this->get("cache");
    // .....
});
//.....

Slim 4:
I am using a container provided by PHP-DI and the following code does not work.

$container = new Container();
$container->set("cache", function () {
    $redis = new Redis();
    $redis->pconnect(REDIS_HOST, 6379, 3, REDIS_PREFIX);
    $redis->setOption(REDIS::OPT_PREFIX, REDIS_PREFIX);
    return $redis;
});
AppFactory::setContainer($container);
$app = AppFactory::create();
$app->add(function (Request $request, RequestHandler $handler) {
    $cache = $this->get("cache");
    // .....
});
//.....

[jacekkarczmarczyk]

@l0gicgate some frameworks/libs provide an upgrade guide, list of steps you need to do to make your app compatible with new version, something like

Before:

App::useRouter($router)

After

$app = new App();
$app->addRouter($router)

Maybe there could be something like this for Slim too? See for example https://vuejs.org/v2/guide/migration.html or https://github.com/vuetifyjs/vuetify/releases/tag/v2.0.0#user-content-upgrade-guide

@l0gicgate Imma be real with you chief. This ain't it. Mainly because there's no DI-Bridge in my case. Do you know if that's going to be supported for v4 anytime soon? Really can't go without it.

Other thing that might be a bug. When you search using the search bar in the v4 documentation it often links to the v3 docs.

[l0gicgate]

@Rutmeister you don’t need DI bridge. You can use any PSR-11 container implementation you want with Slim 4.

Go look at https://github.com/slimphp/Slim-Skeleton it uses PHP-DI with Slim 4.

Also, the doc search is not broken, the new docs were just released so we had to trigger a recrawl via Agnolia which takes several days to complete. It’ll be fixed shortly.