I’m trying to find a way to safely modify the routing parameters in an routing pipeline step.
My problem is that I have a page that might require rather complicated activation parameters and those must be configurable and stored in database along with the navigation menu structure.
What I was thinking was to just add a query string parameter to the link (like ?get_config=1) and, in a preActivate step, if I have the parameter, fetch the configuration from the server before forwarding the request with this config added to the parameters that will be passed to the activate method of the viewmodel.
I tried modifying the routingContext in my pipeline step but with no effect on the activation parameters. Aurelia seem to be getting those from another object and I’m not sure if I can safely modify anything in there…
Thanks for your answer.
Actually, it would be easier but I would like this mechanism to fit inside the architecture instead of being a responsibility of the individual modules’ developers.
In that optic, it would be nice if the dev just received the configuration in the activation parameters as any routing param instead of having to fetch it himself and having to know the underlying structure…
In that case, you might want to consider aurelia-store. An approach can be that you read the parameters from the route, populate the store, and the individual routed view-models subscribe to store; thereby when the property is changed from pipeline step, the view models are notified of the change.
As far as I can remember, the router parameters are frozen.
Ok thank you @Sayan751 . I’ll try to work in another direction (maybe not the store because I don’t want to add this plugin just for that case). Thank you!
If anyone else has additional insight, I’m still interested, though!
I just tried to modify the lifecycleArgs of the instruction in a pipeline step and I seem to get my information in the activate method so apparently it is possible to modify them.
maybe instead of trying to modify the url parameters you can use a redirect.
create a route that doe’s nothing except redirecting to other routes.
so you might have a url like “/redirect?config=1” pointing to a “redirect component”.
in the “activate” lifecycle of that component - you fetch the data based on the configId you got in the url, and then perform a redirect to a new route with real parameters.
that way - you can navigate to those routes using the real url, or by using the “redirect” url.
