As discussed on Slack, there are a few issues with the way FastRoute\Dispatcher returns information after a route has been dispatched.
Issues
FastRoute\Dispatcher::dispatch() returns an array with an inconsistent structure- It only appends allowed methods to the return value when no allowed methods have been found on the dispatched route.
Solution
As discussed, I proposed that we implement our own dispatcher based on the logic found in FastRoute\Dispatcher\GroupCountBased. Our dispatcher would return a DispatcherResults object which would have the following methods:
::getStatus() which would return Dispatcher::FOUND, Dispatcher::NOT_ALLOWED or Dispatcher::NOT_FOUND::getAllowedMethods() which would return the allowed methods for dispatched route. This would be done dynamically as it has to loop through all the routes in order to compute the allowed methods. This is the exact reason why at the moment it is only done when the Dispatcher::NOT_ALLOWED status is being returned. This way, we offset the overhead on the end-user when they call this method.::getHandler() when the route is found, this is the way we get the handler (callable) associated with the found route.
Implementation
@akrabat mentioned that we could implement this in 3.x and append the DispatcherResults object generated to a request attribute dispatcherResults or dispatchResult and consequently phase out routeInfo on 4.x which is currently being appended while routing is done.
Questions
- Are you in favor of this implementation?
- Should we implement it in
3.x and phase out routeInfo in 4.x
- Should the new attribute be called
dispatchResult or dispatcherResults
- Should the object returned by our dispatcher be
DispatcherResults or DispatchResults or something else.
Status
- Proof of concept of custom Dispatcher can be seen here
- Need to finalize discussion
As discussed on Slack, there are a few issues with the way
FastRoute\Dispatcherreturns information after a route has been dispatched.Issues
FastRoute\Dispatcher::dispatch()returns an array with an inconsistent structureSolution
As discussed, I proposed that we implement our own dispatcher based on the logic found in
FastRoute\Dispatcher\GroupCountBased. Our dispatcher would return aDispatcherResultsobject which would have the following methods:::getStatus()which would returnDispatcher::FOUND,Dispatcher::NOT_ALLOWEDorDispatcher::NOT_FOUND::getAllowedMethods()which would return the allowed methods for dispatched route. This would be done dynamically as it has to loop through all the routes in order to compute the allowed methods. This is the exact reason why at the moment it is only done when theDispatcher::NOT_ALLOWEDstatus is being returned. This way, we offset the overhead on the end-user when they call this method.::getHandler()when the route is found, this is the way we get the handler (callable) associated with the found route.Implementation
@akrabat mentioned that we could implement this in
3.xand append theDispatcherResultsobject generated to a request attributedispatcherResultsordispatchResultand consequently phase outrouteInfoon4.xwhich is currently being appended while routing is done.Questions
3.xand phase outrouteInfoin4.xdispatchResultordispatcherResultsDispatcherResultsorDispatchResultsor something else.Status