Question: Circumstances to trigger reroute based on query parameters

[netaisllc]

Describe the question
I have a question about the decision made in this closed issue: #322

Additional context
Issue 322 was reported as a bug wherein rerender was not being triggered on routes of the same path but with different search (query) parameters. This issue was addressed in code, in that indeed, a re-route occurs when only the search parameters change.

My question is: is there a way to work around this? In effect to revert the change on a route-by-route basis?

Below is more context.

Maybe it's only me or my team, but using ?key=value seems to be the conventional way to additionally qualify a "route" without actually changing it.

Our use case is a mapping app wherein on mount we read the uri to hydrate the app to a given state and track crucial aspects of the view in the search property as an operator zooms/pans/moves around it.

For us, the "route" doesn't change - the operator is viewing such-and-such map - but yeah, the locus, zoom, bearing, pitch, and a lot of other stuff may change as dictated by the actions of the operator. We track all that as query parameters so that any arbitrary uri can be shared and when rendered will result in the "same" map view.

This is not intended as shade on this great project, rather as an attempt to gain more understanding and perhaps a pattern by which we can get around the current behavior. Any remarks would be helpful.

Thank you.

KJM for Hivemapper.com

[frehner]

For clarity - are you asking for search param changes to not fire pushState when you’re on certain (or all?) routes?

If so, in my opinion that seems like a reasonable request.

What do you think an ideal solution for you would look like?

For reference, we did something somewhat similar here #484 so maybe we could model this solution after that too?

[netaisllc]

@frehner Thanks for the reply. Basically, I'm just looking to understand the rationale for the current behavior of single-spa; I believe this snip from Issue #484 provides it:

A router generally calls pushState() or replaceState() before triggering a re-render of its code.

I think our use case differs from that assumption. (We have chosen to track some secondary state in the uri and use replaceState to do that.) It seems like doing so will direct single-spa to invoke a page reload without recourse. (BTW we're using LayoutEngine in our POC if that matters)

So yeah, one way (perhaps naive) to get around this would be to support a declarative property of a 'route' to direct single-spa to ignore search parameter changes when determining if a re-render is needed.

Warning: this idea is submitted without any knowledge of wider ramifications or work effort to do so.

[frehner]

I think that issue comment you linked to is probably the best summary of the rationale -- single-spa needs a way to notify all routers that they need to rerender, and currently there is no browser-standard way to do so. For additional information, see this proposal that I've created that is related whatwg/html#5562

Back to your problem - do you think you could utilize the evt.singleSpa property as detailed here to prevent some unnecessary renders in your app? https://single-spa.js.org/docs/api/#popstateevent

[netaisllc]

Interesting proposal. As for our situation, since it is a POC, we have some time to investigate alternative paths.

It's a good idea to explore listening for popstate or other single-spa routing events. That said, I'm not clear on how that will help. That is, I think the problematic behavior is that my spa is being remounted based on the above discussed result of a detected route change. (Technically, single-spa cannot actually "re-render" as it has no idea of the rendering model any arbitrary registered app uses -- at least that's my presumption...)

This is all still new ground to cover so I'm going to look more into the LifeCycle methods to see what I can get from a deeper understanding of them.

[frehner]

It definitely shouldn’t be remounting in those situations.

If you can provide an example repo, we can look into it.

[netaisllc]

Thanks, but I'm thinking this is the result of Pilot-Error on my part. Not an actual Issue.

[frehner]

Sounds good. Let us know if you find anything