Rework routing.

1. Remove dependencies in the constructor of the Router class. Encapsulate the RouteCollection class in the Router class. Add method setCollection(RouteCollection $collection), for tests.

2. Make the RouteCollection class a collection, no matter how strange it may sound. That is, implement only the 'set/add/put', 'get' and 'all' methods. Move all the logic of route formation to Router.

3. For the route key, use 'domain/from' instead of 'as (option)' or 'from'. This will remove the problem of rewriting routes for different domains, but the same paths. Which will also allow you to cache routes.

PHP Code:

$routes->get('/', 'Controller::default');
$routes->get('/', 'Controller::another', ['hostname' => 'another.domain']);
$routes->get('/', 'Controller::subdomain', ['subdomain' => 'subdomain']); 


php spark routes  // The first route was overwritten by the second one, and the third one was discarded.

Code:

CodeIgniter v4.3.1 Command Line Tool - Server Time: 2023-01-25 04:54:01 UTC+00:00

+--------+-------+------+--------------------------------------+----------------+---------------+
| Method | Route | Name | Handler                              | Before Filters | After Filters |
+--------+-------+------+--------------------------------------+----------------+---------------+
| GET    | /    | В»    | \App\Controllers\Controller::another |                | toolbar      |
+--------+-------+------+--------------------------------------+----------------+---------------+

An array of named routes is generated on the first request. Perhaps it can also be cached.

4. The Route class can store route data, some logic, and also allow you to suggest methods with options in the IDE (instead of an array to define options) as in Laravel. This class can also be passed to the IncomingRequest class in order to get access to the path or route parameters in the application.

PHP Code:

$request->route->is('post/*'); // This can be handy in filters. 


5. Implement named route parameters like Laravel, Symfony or Yii. This will allow you to access the parameters by name, it is easier to generate a URL.

PHP Code:

$routes->get('post/<post>/comment/<comment>', 'Controlle::method/$post/$comment')->domain('<locale>.example.com')->name('comment');
// Although I would look towards the ServiceContainer and autowiring instead of specifying variables in the handler.

route_to('comment', ['comment' => 1, 'locale' => 'jp', 'post' => 2]); // jp.example.com/post/2/comment/1
$request->route->param('comment'); // 1   


Also in the future it will allow to implement the ServiceContainer and Autowiring (at least in the controller).

I expect comments about breaking changes and version 5 (which most likely will never be). But if we do not improve the framework, it will turn into 2.x / 3.x
Although I do not use the framework, I think the changes I proposed can be positively received by the developers.

I generally agree, but I don't agree with everything.

Realistically, I think it is a good idea to implement it gradually little by little so as not to break existing apps (unless devs are extending framework classes).
I don't think it is good that rewriting everything for v5.

The output of spark routes described in 3 is a bug.
I sent a PR: https://github.com/codeigniter4/CodeIgniter4/pull/7176

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

I believe that the current state of the framework is a consequence of the fact that the developers had a desire to make 4.x similar/compatible with 3.x.

As a result, frameworks use named parameters when CI was 3.x and earlier, and for 4.x these are already breaking changes.
At the end of CI 4.x will drive itself into the pit of 2.x and 3.x, so 5.x will be just a minor cosmetic change so as not to break compatibility.

---

Maybe I'm wrong. Maybe I have such ideas because I do not use this framework and critical changes do not play such a role for me as for active users of the framework.

@kenjis Can you express what you disagree with?