Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Allow for state params in pushState

See original GitHub issue

Starting to use your library with Svelte 3. This is either a question or feature request…

I see the pushState events are basically using the state param for the uri. This removes ability to history.pushState(someRouteState, ...) right?

Seems like it would be nice to have pushState state param, say, default to null but be available to use… when caching some route data like here:

https://twitter.com/ryanflorence/status/1111272046372093953

None of the other generic routers seem to handle this well OR they don’t handle search params well or something. Yours is best so far and small. But having state available would be nice.

Issue Analytics

State:
Created 4 years ago
Comments:5 (3 by maintainers)

Top GitHub Comments

1reaction

cdock1029commented, May 7, 2019

No worries 👍… I think the canonical example is just a slight optimization when routing to sub route where you have the data already, which then it’s just the initial state (state || undefined), so not too complex in that case and consistent on refresh.

Other than that, I could see wanting to stay consistent with native API, but it’s not super necessary to have I guess.

On Tue, May 7, 2019, 16:31 Luke Edwards notifications@github.com wrote:

Ah sorry @cdock1029 https://github.com/cdock1029. I drifted off the other night~

Still open to discuss this, but I still don’t think history state belongs in most SPA setups given the issues above. Sounds like maybe you arrived to same conclusion?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lukeed/navaid/issues/6#issuecomment-490244030, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGD6GWESWC2CK5SCK3BTQLPUHRLXANCNFSM4HKW4KEA .

1reaction

lukeedcommented, May 3, 2019

Hey, thank you

I thought about this initially, but it’s a really unreliable thing to do. Problem is that if you’re not explicitly providing defaults and fallbacks on every single route (or every single time you read history state) then you will have faulty/undefined data.

For example, / to /about to /blog/hello-world

If that’s the path you plan for, should be fine. But if user enters your app AT /about or AT any blog post, you’d have to manually define the fallback data you expected to have, or suffer errors.

You basically end up coding the app twice

IMO it’s much better to just rely on the URL since that’s common to all entry points and all rendering contexts, including server-side.