Meteor UI Pattern: Keeping App State on the URL

I haven’t written a tutorial for a long time.
So, I decided to write a tutorial about keeping states on the URL.
This seems to be a very simple topic, but it’s leads to a very interesting discussion.

By keeping your application state on the URL keep things simple and users will love it.

I’ll show you some patterns and sample codes with real world examples.

Read It Now: Keeping App State on the URL

Hope you’ll like it.

2 Likes

It would be good to have more description about how a complex app like the dashboard can keep all of the state in the URL!

It’s not that hard and may be depend from app to app.
But in our case, there are only few parameters like time, data resolution, metric groups.

Most of the time it’ll be a finite number of states. We could place them in either route params or query params.

State does not mean data for dashboard. Just some pointers to retrieve data.

Yeah, those are exactly what I was wondering - I guess in that case it would be best to keep them in query params? Does changing the URL too much break the back button? Should we be careful where we use replace rather than pushState?

Does changing the URL too much break the back button? Should we be careful where we use replace rather than pushState?

We normally(everytime in Kadira) change the URL with an user action. So, it’s totally okay.
And we set queryParams at once. So, it won’t do any harm.

But, automatically adding query string without a user action is not a good idea.