Imagine that a user has interacted with your app that results in a series of url params in the address bar. Now the user hits F5. How is your app supposed to access the query params that are shown in the browser address bar and tell its controllers/components to assume those parameters as properties? My problem is that my app resets all of its properties that define query params, but in reality, the browser has submitted a request to the server using the params shown in the browser address bar.
And what if the user modifies the query params shown in the address by hand? How is the app supposed to detect these changes?
Yes. I’ve gone through all documentation for queryParams as related to Controllers and Routes. What I am missing is how the ‘DD’ part of the ‘DDAU’ (data down actions up) paradigm applies here. It seems like the url params in the browser address bar are not coming down anywhere after F5. Where do these properties come into the app, i.e. where can I set a breakpoint to examine the query params that are currently shown in the address bar? Knowing this would probably set me on the right track.
query params are set to controller values. They are also available in the model hook, but only rely on that if refreshModel is set to true.
If they are set on controller values and you’re not using refreshModel, the timing of when they are set is an implementation detail, and you should generally not worry about it. Just use the value where you need it
Thanks for the suggestions. I did not know the query params were also available in the model hook. My problem ended up being that I was not handling the assignment of some of the param values in a mixin that I am currently using to maintain UI state properties. So it was a simple fix.
What helped, however, was to set a breakpoint in the route’s setupController() hook - this gave me a good starting point to find out where those query param values were coming from and where they were headed.