#remember route data when user hits back button?

92 messages · Page 1 of 1 (latest)

wooden tree
#

You can use context if you want to share data between pages. You can also lift the state up, and pass data via useRouteData hook. There are more options, if these two do not work for your setup.

#

useRouteData does not work?

#

check if there's data, if there is - use it.

#

If not, fetch

#

back button

#

ah

#

not sure what solid router does in that case

#

and what about context?

#

Wrap your routes with shared data

#

If the data is in the context, you can check for it's presence before you fetch?

#

context should take care of that

#

You wrap your app with context

#

Above routes

#

Once you fetch the data, update the context

#

In a different route, read the context - if the data is there, do not fetch - else fetch

#

back button does not reload your SPA

#

Ah, you mean you want something like react-query

#

To keep the fetched data without manual handling

#

Is that it?

#

Yes, that's either manual or a library does that 4 you

#

Framework does not deal with remembering data between routes

#

But tanstack query should be just thing you're looking 4

#

Yes

#

It was react-query, but Tanner decided to go framework agnostic

#

So, that's it

#

If it's an overkill, you'll have to do it manually

#

Or keep it in the DOM

#

You can write your own implementation

#

Put the data in context

#

Route can be your key

#

As I said, createResource does not deal with that

#

It will not be three lines of code

#

You can put your data in context

#

And you can use your route as the key

#

That's probably the primary base for any of these libraries

#

Why would you delete data?

#

Why?

#

you have /foo, /foo/bar and /foo/bar/baz memorized already

#

why would it? There's no guarantee that the data will be stale

#

Or that the user will not immediately go back

#

There are multiple things that you need to wrap when dealing with cached data

#

One of them is stale detection

#

he can click quickly multiple times

#

Yes

#

if these are routes, he should be back

#

browser rembers your routes

#

why wouldn't he be?

#

I don't think that's the case

#

You are talking about relative routes

#

so browser just puts them in history

#

so?

#

I qo to /a, then to /a/b, then to /c

#

All three are in the stack now

#

I can go back

#

But why refetch the data if user can manually come to the page maybe?

#

And the data is not stale?

#

These libraries do that for you automatically

#

You can implement a simple solution

#

And you're right?

#

OK, then

#

Why?

#

Is that like your rule, or something that I'm missing from the general knowledge?

#

It's about cache, and how to handle it

#

And I don't think that you've given it that much thought, certainly not as much as library authors

#

This is back-forward cache

#

And the browser decides to do that

#

In SPA case, it will not kick in

#

So, you have to do that manually

#

As I said, there are multiple libraries that do these things

#

You can implement your own whatever way you want

#

It's not the default browser behavior to not reload the page on navigation

#

It's JS

#

LIbraries are keeping the data in the cache

#

So that you would not have to handle that manually

#

That's the high level

#

It will load the new page

#

And you will see the page loading if you navigate to a different url

#

Unless it's a link on the same page

#

It's back-forward cache

#

It will just restore the DOM

#

There's nothing to emulate

#

THat doesn't work with SPAs

#

ANd browser has it's own logic determining tis

#

this

#

You implement your own logic

#

You can not know where did the user came from

#

The browser keeps that part for user privacy

#

So you can't be sure

#

How would you be sure?

#

You are tracking the user

#

It's not the same as using browser APIs