More info on v5 changes

[andrewnicols]

I work with Moodle and we've been migrating out legacy app to use Slim over the past 2 years.

I've just been looking through the 5.x branch to see how much the changes there are going to impact us but I'm finding that there isn't much information. The git commits aren't much help either because most of the commits contain seemingly unrelated changes under the banner 'Add v5'.

In particular:

• the changelog notes about using middleware for custom route arguments with the removal of Route::setArguments, but I can't actually see how you would do this without the Route. We use Route::setArguments() within a validation middleware to remove undeclared parameters.
• the \Slim\Interfaces\RouteInterface is just gone. No discussion, no alternative, no mention in the changelog. This is something that we use as type hints within our application and there is no apparent alternative or replacement
• no backwards compatibility available and no deprecation for many of these things (like Route::setArguments and fetching the Route from the Request attributes). We're an open source project and while we will be able to fix many of these things in our core platform, our community plugins are going to struggle a lot more to support a wide range of versions

Is there a plan or any discussion for the v5 changes? I'm aware of https://github.com/slimphp/Slim/wiki/Slim-5-Road-Map but none of these breaking changes are mentioned there, and there is no discussion about these. I haven't (yet) found a discussion in the discource channel either.

[odan]

Hi @andrewnicols Thanks for the detailed feedback, this is very helpful. Just to clarify the current situation:

Slim 5 is still in an early proof-of-concept / active development phase. The 5.x branch is not finalized yet and parts of the API are still being refined.

The main goal of Slim 5 is to simplify and "untangle" internal responsibilities, modernize the code base, and make the framework more maintainable in the long run.

Some of the changes (like routing and arguments handling) are part of this internal restructuring and are not necessarily final.

Regarding setArguments() / getArguments(): You are not the only one who has raised concerns about their removal.
We had several issues in the past around route arguments and the new RoutingArgumentsMiddleware was added in v5 to address those issues.

The idea for v5 is to separate the the route definitions from the actual routing result. The the routes arguments are actually an "input" from the request and therefore part and the routing result (and not from the route definiton).

I agree that the current situation may be too restrictive. I will revisit this and evaluate adding the route arguments and the RouteInterface in v5 as well.

no backwards compatibility available and no deprecation for many of these things

Some structural decisions are still being validated through experimentation and feedback, so not everything is finalized yet.
Once the internal design stabilizes, we will document the changes more formally, including a list of breaking changes and migration steps etc. If there are specific areas you are concerned about, we’re very open to discussing them before the API is finalized.