Best way to persist data across routes?

[rafaelrinaldi]

What's the consensus on persisting data across different routes?

I have a form on route /foo and another one on page /bar that uses some info from /foo.

Is session storage (particularly createSession()) the way to go for my use case? Should I use global instead?

I have seen similar questions in here without an answer, so I don't seem to be the only one puzzled by this.

Thanks!

[kiliman]

As with most tech decisions, it depends.

If the data needs to be persisted for long term, then store the data in a database and fetch from each loader.

If the data is tied to a specific user and is only needed for the duration of the session, then use session storage. If the session data is small, then you can use cookies. Otherwise use an external session store.

If you're using cookie sessions, remember all the session data is stored in the cookie. Mutating the session in one loader does not guarantee the other loader will see it, since it will need to have made the round trip from the browser. That is why it's recommended you only mutate session from your action, since there is only one action running at a time.

If you want to save user preferences across sessions, either store in database or a persistent cookie.

If the data is dynamic and useful for all users, then use a cache like Redis or lru-cache.

Generally it's ok to refetch data across loaders. Since loaders run in parallel, and conceivably across different processes, you can't really share data (except with a cache). And remember, most databases also has a cache, so the same query executed multiple times will return from db cache instead of reprocessed.

I would do the simplest way first, then measure with expected load, and refine appropriately.

[sergiodxa]

If the routes are not rendered at the same time (e.g. /1/2) and instead it’s one or the other (e.g. /1 or /2), then you will need a server side cache to avoid going again to the DB

The only similar feature in Remix would be using the session but it’s not intended for that

I recommend you to query again unless you measure it’s slow, then cache it.

[gustavopch]

In some cases it may be possible to pass data via the URL search params too.

[kiliman]

Typically, when you have a list route and a detail route, the data needs are drastically different. The list route typically only needs an id and title for each item to render.

Whereas the detail route will have many more of the item properties. So even if you wanted to use the list data for your detail route, you wouldn't have all the data you needed anyway. Or you would have to return a lot more data from your list route (over-fetching), which is much worse than making an extra data request.

[rafaelrinaldi]

In some cases it may be possible to pass data via the URL search params too.

You have mentioned that twice already as if that wouldn't be the first choice for a simple use case. If you have a bunch of fields or sensitive data you want to persist this approach starts to get iffy.

You can always rely on query params as a naive and framework agnostic data persistence solution but the question is literally about how to approach this problem in the context of the Remix framework.

[sergiodxa]

You could POST to the next route, then in the action of that route return the data from the previous route.

In the second route UI add a hidden input with the data from the first route so you can send it back to the server once the second route also submit a POST

[norayr93]

I am trying to create a countdown in my remix app that is also persistent across page reloads. Using localStorage is not the best choice as the UI becomes inconsistent ( When it's conditional rendering, the transition is taking longer than in CSR apps ).
What is the preferred way of doing it ?

[norayr93]

It's only seconds in my case ( 30s ). Let's assume I am showing a countdown with some text whenever the seconds are less than 30 and Show Start again button to trigger the countdown again. When I refresh the page it should show the existing remaining seconds if there are any. Is your suggestion appropriate for this case? Can you please show or send me some articles or gist of example implementation if there is any?

[sergiodxa]

Yes, you can do new Date(Date.now() + 30) to get the current 30 seconds in the future, and store that in a cookie or session

[norayr93]

One last question - Which one do I need to use - createCookie or createCookieSessionStorage ? I am confused.

[sergiodxa]

The first will give you a Cookie object, inside a cookie you can store any serializable value

The second will give you a SessionStorage object that stores the session data inside a cookie, technically are similar (data is stored in a cookie and serialized), but the SessionStorage one can also store the data somewhere else, that’s why it exists.

For your case you can use any of them, if your app already has a session use that, if not it’s the same.

[norayr93]

@sergiodxa Thanks for the help. My problem was that I didn't understand the cookie API properly. After properly checking the internal implementation, It's easy to implement.

[gustavopch]

/bar?field=value