Same cached component with different params

[Qureshi-DH]

So how this mimics stack based routing is by caching pages. But when we're hitting the same page but with different params, the same cached component is being displayed/resumed.

This becomes a serious issue when let's say we have a page that displays information related to car based on id /car/:id. When we click to Honda X, the same old Tesla Y information from the cache is being displayed.

What I suggest, is to add an option to the StackRouter that caches page against complete URL string (including params). In this way, cached entries will consider params too.

[cdellacqua]

The behavior you're describing is a compromise I made to port the concept of stack-based navigation to the web. The problem I encountered is that, while a native App has a maximum stack size imposed by the navigation rules, the same is not true on the web, where a user doesn't usually go back.

I'm wondering if you could solve the issue by writing a custom handler in your page component: using an onBeforeLoad handler, you could check if the params match the same car and if they don't you could temporarily show a loading state while you fetch new information.

If the above solution isn't what you are looking for, I can try to add an optional caching strategy, keeping the default memory-saving strategy, but allowing for the alternative you are describing.

[cdellacqua]

Another option could be to add setResumable(false) to the car page, but I don't know if that's the behavior you're trying to achieve.

[Qureshi-DH]

setResumable(false) won't resume the page regardless of same or different params.

I currently solved this issue by making my params reactive and setting a reactive function onParamsChange that reloads data on change of parameters. This isn't a good solution but works.

If stack limit is the issue, we can add that option aswell to the StackRouter options and define an apt preset limit. Shouldn't be that big of an issue.

[cdellacqua]

What you did (reacting on params change) is exactly what I usually do, it's the pattern I had in mind during the implementation, in fact you can find this in the readme:

a cached page is uniquely identified by its route template

I'm thinking about the implication of what you describe. The new behavior would be different, because as of right know you have the guarantee that every cachable entry stays in the cache and doesn't get destroyed for the entire lifetime of the browsing session, but having a limit would remove this guarantee. It would probably be a good idea to add a priority flag to determine the order of destructions of items in the cache, for example setting the maximum preservation priority to an infinite scroll page.

Let me know if you'd like to work on that, otherwise I'll give it a try in a few weeks.

[Qureshi-DH]

Instead of setting a flag, the most common practice is to use an LRU cache. Surprisingly, it outperforms all caching strategies. Apart from this, setting the stack size will be in our hands as well. In my opinion, we won't even reach the set stack limit in normal cases unless we're dealing with a huge app, and in that case, it would be optimal for the developer to alter the stack size according to his/her need.

I'm too busy at the moment, but i'll have a look at it. If I'm able to manage time for this, I'll open a PR. You should probably assign a 'Feature-Request' label to this issue.

[cdellacqua]

Thanks, let me know if you manage to dedicate some time to it, otherwise I can give it a try in a few weeks.