You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
continuing my exploration of uri generation with v2 beta1, there are a few things that are still making it difficult to use:
all substitution values must be string - easily fixed with $params = array_map('strval', $params) but ok
no rawurlencode() on substituted values - again, easily fixable up-front but see next point
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?
The text was updated successfully, but these errors were encountered:
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...
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).
Hi @lcobucci
continuing my exploration of uri generation with v2 beta1, there are a few things that are still making it difficult to use:
That last point is the tricky one, because you would expect to:
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?
The text was updated successfully, but these errors were encountered: