FastRoute icon indicating copy to clipboard operation
FastRoute copied to clipboard

Remaining params with uri generator in v2?

Open mikespub opened this issue 1 year ago • 3 comments

Hi @lcobucci

continuing my exploration of uri generation with v2 beta1, there are a few things that are still making it difficult to use:

  1. all substitution values must be string - easily fixed with $params = array_map('strval', $params) but ok
  2. no rawurlencode() on substituted values - again, easily fixable up-front but see next point
  3. no idea which params have been used to generate the uri, and which are "left over" to handle ourselves (incl. encoding etc.)

That last point is the tricky one, because you would expect to:

  • have a way to get them back (pass substitutions by reference + remove them when consumed?), or
  • append them as query string by default (not always applicable)

The use case is that the application will prepare a bunch of parameters, some mandatory and others optional, and expect the uri generator to prepare an URL taking all of these into account for a particular route. This is especially useful if you tweak the routes later, and therefore change which ones will end up as path params and which will remain as query params in each route.

Make sense?

mikespub avatar Nov 02 '24 16:11 mikespub

Hummm that's an interesting thing...

I have some thoughts on how to solve this but they might stretch a bit the definition of a "beta" release (e.g. changing the return type to provide more flexibility)

I might have some time tomorrow or Sunday to play with this a bit...

lcobucci avatar Nov 07 '24 22:11 lcobucci

You could extend the forRoute() method with an optional 3rd argument to add any remaining params as query string, and default it to false.

That way, you don't need to break existing integrations, change return type or behavior by default, and it would fit the 2nd option above.

The 1st option above could be done semi-transparently too, but there would be side-effects if someone expects $substitutions to remain unchanged.

Or you could do both to support either option :-)

mikespub avatar Nov 08 '24 14:11 mikespub

I'm more inclined towards the idea of returning a Stringable object to encapsulate those complexities away - thus the minor BC-break in a beta version.

I don't expect that to be very impactful to people using the new api (only for people extending it).

lcobucci avatar Nov 08 '24 18:11 lcobucci

@mikespub apologies for the huge delay here, the new implementation is there and I'll release a new beta this week).

lcobucci avatar Jun 18 '25 20:06 lcobucci