Storing a basic object

[TwistedMinda]

Imagine we are to fetch lots of information from the database every time the user goes back to the main page.

With jotai, everytime you update an atom with a new value, the observing components will re-render. So we need to split the data into seperate atoms, so that when an information has changed, we only notify the components that need that information.

So you may say, in order to have the best performances, one can just split the object into smaller atoms for more granular updates of the UI. However, there are many cases where it could become very unpractical to split your object into many atoms, for example for your user information (can be a good chunk of data), so we store it "as-is" in an atom.

Given those 2 constraints, it feels like "selectAtom" would be the best choice to read from the objects. But it feels very redux way, and will require "deepEqual" comparison strategy in most cases to really work, which seems not ideal in terms of performances, especially when updates will be frequent.

Is there any other way to handle this gracefully?

Thank you!

EDIT: I got a second thought on this. If i'm correct, it's as simple as the next statements:

• if the data requested from database will be different frequently (eg. crypto app), i'm actually happy to not have any specific check against the object properties that would be used to prevent useless renders. That's where you don't want to be using selectors that will check against the data, because they will almost always fail and then the DOM will check against the difference in the tree, too.

• if the data requested from database will be rarely different (eg. user's information), i'm actually happy to have the ability to use selectors, in order to prevent useless renders every time we re-fetch. In the other way, if you need to optimize even better, you can still split your object in multiple atoms, and you get the best possible performances for the biggest possible hustle (making an atom for each one of the properties of ur user ....)

Thinking with 2 ways, that I can do.
Am I missing something ?

[dai-shi]

Have you seen https://jotai.org/docs/advanced-recipes/large-objects?

selectAtom is actually only meaningful if you need equalityFn, and it's an escape hatch.

const derivedAtom = selectAtom(baseAtom, x => x * 2);
// can be written as
const derivedAtom = atom((get) => get(baseAtom) * 2);

focusAtom can create a writable atom. selectAtom can create only a read-only atom.

[TwistedMinda]

@dai-shi Yep, pretty much confirming my thoughts. selectAtom is the good way to go.

• Fetching data from database

• New object reference everytime so components listening baseAtom will re-render everytime

• If data is supposed to be almost always different (eg. Weather app)

  • Don't use selectors, as they will still allow re-render anyway because the resulting values always differ <= small gain of performance

• If data is supposed to be less frequently different (eg. fetching user profile info)

  • Use selectors to allow re-renders only where a/some specific values within the object really changed values <= small gain of performance
  • Don't make heavy computation in selectors as their function will be triggered everytime their parent(s) update (even though they don't allow a render in the end).

Sad to admit redux's selectors paradigm seems to be the only way to handle this correctly, without having hundreds of atoms manually created (one for each of the object's property).

I'm good to go!
Thank you