feat(utils/useHydrateAtoms) - Optionally rehydrate with force hydrate

[SariSabouh]

Related Issues or Discussions

The useHydrateAtom discussion has been live since August of 2021 in #669.

Summary

We found a use case within our project that required a rehydration after a specific event. We had to manually rely on conditional useEffect actions to manually update the store rather than hydrating back from a fully reset SSR page. After review, a forceHydration option meets that requirement and a lot of the cases mentioned within that option discussion.

Check List

• yarn run prettier for formatting code and docs

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
jotai	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 15, 2023 2:42pm

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit c4c5e4c:

Sandbox	Source
React	Configuration
React Typescript	Configuration
React Browserify	Configuration
React Snowpack	Configuration
Next.js	Configuration
Next.js with custom Babel config	Configuration
React with custom Babel config	Configuration

[dai-shi]

Thanks for your suggestion. Added some comments.

[SariSabouh]

Added all requested changes @dai-shi

[dai-shi]

On second thought, we could do and suggest to use store api for such use cases.

const Component = () => {
  const store = useStore()
  store.set(countAtom, countValue)
  // ...
}

What do you think?

[SariSabouh]

On second thought, we could do and suggest to use store api for such use cases.

const Component = () => {
  const store = useStore()
  store.set(countAtom, countValue)
  // ...
}

What do you think?

Basically disregard the forceHydrate and suggest using the store API? If yes, that could technically fully replace the useHydrateAtom though and may cause many re-renders in some cases, especially if its an object compare.

[dai-shi]

Basically disregard force hydrate, but store api wouldn't fully replace useHydreteAtoms which ensures only setting values if unset.

may cause many re-renders in some cases

I'm not sure if I get those cases.

[SariSabouh]

Basically disregard force hydrate, but store api wouldn't fully replace useHydreteAtoms which ensures only setting values if unset.

may cause many re-renders in some cases

I'm not sure if I get those cases.

I can try to re-produce it again but I remember going for the forceHydrate because useStore was was causing a re-render. Is there a reason you're opposed to going with some sort of re-hydrate method? I was thinking we can integrate atomsWithReset somehow instead.

[dai-shi]

The reason to be against dangerouslyForceHydrate (the name is actually good to warn the usage) is that it bypasses the hydration check, and the result is just equal to store.set(...). It means we provide two ways for the same capability which we carefully avoid in Jotai API design.

[SariSabouh]

So you are suggesting that we do something like this:

export const Component = ({
  componentPreferences,
}: ComponentPageProps) => {
  useHydrateAtoms([[componentPreferencesAtom, componentPreferences]])
  const store = useStore()
  componentPreferencesValue.reset &&
    store.set(componentPreferencesAtom, componentPreferences)

Which this code removes the need for useHydrateAtoms because .reset could be controlled that its reset only at the need for a re-hydrate

[dai-shi]

I'm not sure if I understand the purpose of "reset", but my suggestion was if you use store.set() you don't use useHydrateAtoms.

Ah, I see you want to force hydrate if reset is true, and otherwise, only hydrate initially.
Hm, that use case supports this PR's change.
My suggestion to go against this PR would require store.has() method which doesn't exist.

[SariSabouh]

I'm open to ideas. The issue is that we hydrate a page with data that is needed until a certain action completion. Once this action is completed, we want to fully reset that atom and get new data from SSR on next time this page loads.

[dai-shi]

I feel like merging this PR as the code is clean and it has dangerously prefix to warn the usage.
After all, it is in jotai/utils which is a little less strict about API design.

we want to fully reset that atom and get new data from SSR on next time this page loads.

I'm curious about your case. When you get new data from SSR on next time, how would the store be kept in memory (assumed so because you want to fully reset) ?

[SariSabouh]

We have a store instance that stays maintained, and the only thing we fully reset is that specific atom.

So basically here is the flow:

1. Store is create at app init
2. User reaches an SSR page called X
3. SSR pages gets hydrated using useHydrateAtoms based on data retrieved from APIs
4. If the user navigates between pages back and forth, we do not want to re-hydrate, as designed by Jotai
5. If the user goes back to page X, and completes a certain action
6. The hydrated atom on page X should be fully reset and re-hydratable.

That is how we got to where we are. I was hoping atomWithReset will take care of that, but based on Jotai code it does not as nothing now can re-hydrate. Hence this PR.

[dai-shi]

and completes a certain action

Hmm? If this is a user action, we should update atoms at the same time. Updating atoms in render is something we should really avoid. It's not just bad practice, but theoretically delayed.

[SariSabouh]

So once the user completes the action it takes him out of the page. And they won't get the newest set of data until they reach that page.

Like once you complete checkout, you are taken out of checkout and your checkout data is reset. However, once you come back from checkout, you need the newest set of data from the server to be hydrated again. Client side won't know the data until they reach checkout, which is SSR.

[dai-shi]

I'm not exactly sure how the second SSR&hydration work, but it sounds like you can only get the new data from props. In that case, the render time updating wouldn't be avoidable. Can't be helped because you don't have control, right? Sounds fair enough, because we usually suggest useEffect for sync with props, but that's far from ideal.

[SariSabouh]

Exactly. We want to avoid the useEffect as it was adding unnecessary complexity and conditions that are not needed. I agree with the hydrate once design, but a reset after checkout seems common enough.

[dai-shi]

I think there should be a better way, probably atoms-in-atom or jotai-molecules, and we want to educate such ones for common use cases.

This PR change helps as an escape hatch for edge cases, so I want to merge, but we shouldn't teach people to use it for common cases.

[dai-shi]

Thanks for the discussion. It was convincing. I will merge it later.

[SariSabouh]

I think there should be a better way, probably atoms-in-atom or jotai-molecules, and we want to educate such ones for common use cases.

This PR change helps as an escape hatch for edge cases, so I want to merge, but we shouldn't teach people to use it for common cases.

Haven't messed with jotai-molecules yet, but definitely will give them a shot!