Replies: 11 comments 41 replies
-
|
Before diving into it and suggesting a best practice, let me note from the library perspective, or even from React perspective in general. (I don't know what people mean by "hydrate", so I'd use "initialize" meaning "initialize from the server data".) We can "initialize" in the React render phase, only if the data is empty. // suppose we have a cache (this is like jotai's atom value map).
const cache = new Map()
const Component = ({ id, valueFromServer }) => {
// we can update the cache if it's empty
if (!cache.has(id)) {
cache.set(id, valueFromServer)
}
return (
<div>value: {cache.get(id)}</div>
)
}So, if you want to make this component to update cache on re-render, we have to use // value is either from server or from client
const Component = ({ id, value }) => {
if (!cache.has(id)) {
cache.set(id, value)
}
useEffect(() => {
cache.set(id, value)
}, [id, value])
return (
<div>value: {cache.get(id)}</div>
)
}Does it make sense so far? |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the options. In my reply, I didn't want to jump to solutions, I would rather explain why the decisions was made and what limits us. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @dai-shi ! I agree on the confusion that the term I think the options you provided make sense generally! When I started playing around with alternatives, this is similar to the direction I took. There is a subtle issue though which I have not done anything about yet. With all these options, there is still the case where the Perhaps we can leverage the cache that the hydrate hook uses, and if there is a value, defer to the other client side syncing hook. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
The cache in useHydrateAtoms is rather a workaround. We should improve it later. So, while we can leverage it at this point, maybe we shouldn't. Take Option 2 as an example. So, what happens if we set value in useHydrateAtoms and set the same value in useSyncAtoms. As the value is the same, it will be NO-OP. This is really lightweight and it's just a difference between As you say, we can skip the entire check in the initial render. That's true, and it's going to be like this in Option 3 (again, technically the same in 1 and 2). const useHydrateAndSyncAtoms = (values) => {
useHydrateAtoms(values)
const sync = useAtomCallback(useCallback((_get, set) => {
for (const [a, v] of values) {
set(a, v)
}
}, [values]))
const isInitial = useRef(true)
useEffect(() => {
if (isInitial.current) {
isInitial.current = false
} else {
sync()
}
}, [sync])
}I'm not sure if this really works for all cases. |
Beta Was this translation helpful? Give feedback.
-
|
yep, that makes sense. The issue I see, however, is the In the example app I have above, when someone loads a post page directly, the data atom will be hydrated once the client loads. If we have a I'm not exactly clear on what you mean by:
Do you mean that even if we do something like this: useHydrateAtoms(value); // sets value
useSyncAtoms(value); // sets value againbecause of optimizations in core, we don't have to worry about duplicate set actions? |
Beta Was this translation helpful? Give feedback.
-
Yes, I understand what you mean. What I mean is why useHydrateAtoms does so is because we don't have a capability in core and it's currently suboptimal. (but this is not the current point of discussion.) On the other hand, useSyncAtoms is (can be) already optimized as core does it. So,
Yes, this is what I meant. I just realized a big thing. Because useHydrateAtoms is designed to be a replacement of In summary: useHydrateAtoms can set "initial" value of any atoms (like Provider) in render phase. useSyncAtoms can set (initial or not) value of non-derived atoms in commit phase. duplicate set actions issue is too trivial as core bails out for the same values. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed post, it has a lot of insights about a use case, that we currently don't support. However, In terms of enforcing I hope this explains the design choices of |
Beta Was this translation helpful? Give feedback.
-
|
Yep, this makes a lot of sense, thanks for the additional context around the design choices and how we go here!
Just for clarification, can you expand on what you mean by this? Most of the issue I described above is around client side updates, and as such there isn't a need for deterministic updates between server and client.
Yeah this makes sense! Was there any public discussions around this so I can go and get more context? Thanks so much! |
Beta Was this translation helpful? Give feedback.
-
|
I've run into a similar problem as @aulneau in my Remix app, when hydrating atoms with values from loaders. Sample code: // app/routes/index.jsx
import {userAtom} from '~/user'
export const loader = ({request}) => {
return getUser(request)
}
export default function Index() {
const user = useLoaderData()
useHydrateAtoms([[userAtom, user]])
return <Dashboard />
}It's probably a Remix edge case, but when there's a redirection chain, let's say |
Beta Was this translation helpful? Give feedback.
-
|
useHydrateAtoms is a primitive hook and only provides a single functionality: set "undefined" atom value for the first render. This should be similar to how ReactDOM.hydrate() is used. We are still looking for best practices and recipes to create custom hooks with useHydrateAtoms. In your use case, I see two options: 1) use |
Beta Was this translation helpful? Give feedback.
-
|
I very much agree. Same for other packages, like Recoil or react-query. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @dai-shi. I agree about the simple principle behind having a hydration hook. I actually copied some version of |
Beta Was this translation helpful? Give feedback.
-
|
My team have run into a similar issue on using export const getServerSideProps = (ctx) => {
const initialValue = ctx.query
/** some code **/
return {
props: {
initialValue,
}
}
}
/** _app.tsx **/
const App = ({ pageProps, Component }) => {
useHydrateAtoms//([
[atomA, pageProps.initialValue]
])
/** rest of code **/
}When Next.js renders the page upon each request, Here comes the issue. Since We solved this issue by using /** some code **/
return (
<Provider initialValues={
[
[atomA, pageProps.initialValue]
]
}>
<Component />
</Provider>
)This resulted in Shouldn't |
Beta Was this translation helpful? Give feedback.
-
|
Yes, you are getting it right. At first, I developed only
Yeah, if it's a new Provider, because new Provider will create a fresh store. |
Beta Was this translation helpful? Give feedback.
-
|
I believe it would be really helpful if this is documented somewhere in docs or Next.js Jotai docs. |
Beta Was this translation helpful? Give feedback.
-
|
This is actually the discussion thread to talk about what to document. So, this has been a nice discussion. Thanks for opening it up. What would you suggest to document in docs so far? @shahkeyur @Thisen What's your opinion about documenting it? |
Beta Was this translation helpful? Give feedback.
-
|
@dai-shi It seems it is a bit unclear on the usage of Looking at the test code, it seems providing a custom scope is necessary to split the scope of the Provider...? Am I correct? Would |
Beta Was this translation helpful? Give feedback.
-
|
It's true that our examples are generally missing for SSR. It's mainly due to my unfamiliarity. @Thisen might be able to work on it. You are also welcome to improve such things. The scope of Provider is only necessary to have different store in a single session. I don't think we need to use the scope for SSR sessions. Basically, |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if this is right or not. In my app, I have a client-side cookie with a JWT, and this is how I decide if the user is logged in or not. The time to live on that cookie is 15 min and after that, it must be logged out. I realize during router pushes the component does not get re-rendered: https://nextjs.org/docs/api-reference/next/router#resetting-state-after-navigation So, I basically did that: /*
* This hook is used to revalidate the session on every page load.
* The session is revalidated by checking the JWT token's expiry time.
*
* In SSR pages we re-hydrate the atom by calling useHydrateAtoms()
*
* In SSG pages we have to force it as suggested in the docs:
* https://nextjs.org/docs/api-reference/next/router#resetting-state-after-navigation
*/
export const useHydrateSession = () => {
const updateLoggedIn = useUpdateAtom(isLoggedInAtom)
const isLoggedIn = !!parseCookies()[MW_JWT_TOKEN]
useHydrateAtoms([[isLoggedInAtom, isLoggedIn]] as const)
useEffect(() => updateLoggedIn(isLoggedIn), [isLoggedIn, updateLoggedIn])
} |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't look bad. |
Beta Was this translation helpful? Give feedback.
-
|
I can't make it work in my case. Data in // _app.tsx
const initialState = [
[profileAtom, pageProps.profile],
[studentsAtom, pageProps.students],
[lessonAtom, pageProps.lesson],
...
];
return (
<JotaiProvider initialValues={initialState}>
<Component {...pageProps} />
</JotaiProvider>
)// index.tsx
export async function getServerSideProps(ctx) {
...
const { profile } = await getProfile(user, client);
const { categories } = await getCategories(client);
...
return {
props: {
profile,
categories,
},
};// [lessonId].tsx
export async function getServerSideProps(ctx) {
...
const { profile } = await getProfile(user, client);
const { categories } = await getCategories(client);
const { lesson } = await getLesson(user, client);
...
return {
props: {
profile,
categories,
lesson
},
};
|
Beta Was this translation helpful? Give feedback.
-
Right, that's why we created |
Beta Was this translation helpful? Give feedback.
-
|
here's example: https://stackblitz.com/edit/nextjs-oyan74?file=pages/[id].tsx |
Beta Was this translation helpful? Give feedback.
-
|
i just made it work by passing page |
Beta Was this translation helpful? Give feedback.
-
|
I would like to store a value that comes from serverside props and use it all over the application. I've used const useSyncAtom = (state) => {
const [[atom, data]] = state
const set = useUpdateAtom(atom)
useEffect(() => {
set(data)
}, [set, data])
}
const useHydrateAndSyncAtoms = (atom, data) => {
const [initialValues] = useState(() => new Map([[atom, data]]))
useHydrateAtoms(initialValues)
useSyncAtom(initialValues)
}
export default function CompanyDetail({ companyId }) {
useHydrateAndSyncAtoms(companyIdAtom, companyId)
return <CompanyDetailPage />
} |
Beta Was this translation helpful? Give feedback.
-
|
What's the example with I got 19 | const useHydrateAndSyncAtoms = (atom, data) => {
20 | const initialValues = useRef(() => new Map([[atom, data]]))
> 21 | useHydrateAtoms(initialValues)
| ^
22 | useSyncAtom(initialValues)
23 | }const initialValues: MutableRefObject<() => Map<any, any>>
Argument of type 'MutableRefObject<() => Map<any, any>>' is not assignable to parameter of type 'Iterable<readonly [Atom<unknown>, unknown]>'.
Property '[Symbol.iterator]' is missing in type 'MutableRefObject<() => Map<any, any>>' but required in type 'Iterable<readonly [Atom<unknown>, unknown]>'.ts(2345)
lib.es2015.iterable.d.ts(51, 5): '[Symbol.iterator]' is declared here.It's fixed with: const useHydrateAndSyncAtoms = (atom, data) => {
const { current: initialValues } = useRef(() => new Map([[atom, data]]))
useHydrateAtoms(initialValues)
useSyncAtom(initialValues)
} |
Beta Was this translation helpful? Give feedback.
-
|
Removing const useHydrateAndSyncAtoms = (atom, data) => {
const initialValues = useConstant(() => new Map([[atom, data]]))
// useHydrateAtoms(initialValues)
useSyncAtom(initialValues)
}So I replaced const set = useSetAtom(companyIdAtom)
useEffect(() => {
set(companyIdAtom)
}, [set, companyIdAtom])It's good? FYI @dai-shi @hamitaksln |
Beta Was this translation helpful? Give feedback.
-
|
By using useHydrateAtoms along with useEffect, you can make sure that the first render has the correct value. In other words, if it works without it, your use case didn't need it in the first place. |
Beta Was this translation helpful? Give feedback.
-
|
Some questions:
|
Beta Was this translation helpful? Give feedback.
-
If I understand the question correctly, useHydrateAtoms accepts iterable, so both work. jotai/src/utils/useHydrateAtoms.ts Line 15 in adfe227
Originally, I thought it should be a bulk action, but in v2 API, it will simply call one by one. So, it shouldn't matter.
|
Beta Was this translation helpful? Give feedback.
-
|
I run into the problem with nextjs and react query. To make it work I had to wrap the application with import { useEffect, useMemo } from 'react';
import { atom, useSetAtom } from 'jotai';
import type { useHydrateAtoms } from 'jotai/react/utils';
const isSSR = typeof window === 'undefined';
export const useSyncAtoms: typeof useHydrateAtoms = (values) => {
const syncAtomsAtom = useMemo(
() => atom(null, (get, set) => {
for (const [atom, value] of values) {
set(atom, value);
}
}),
[values])
const syncAtoms = useSetAtom(syncAtomsAtom);
isSSR && syncAtoms();
useEffect(() => {
syncAtoms();
}, [syncAtoms, values])
}; |
Beta Was this translation helpful? Give feedback.
-
ProblemuseHydrateAtoms is setting the value only once as expected. However, this could cause issues if you need a clean slate on something like checkout as shown in the example below:
I understand that this is happening due to they hydratedMap that has the atom that was already hydrated here, and it seems like there is no straightforward way around it. So I would like to propose a couple of options to handle scenarios like the above, which are very common. Option 1Update the export function useHydrateAtoms<T extends Iterable<AtomTuple>>(
values: InferAtoms<T>,
options?: Options
) {
const store = useStore(options)
const hydratedSet = getHydratedSet(store)
for (const [atom, value] of values) {
const atomHydrated = !hydratedSet.has(atom)
if (options?.forceHydrate || atomHydrated) {
// if atom exists then update value {} else
hydratedSet.add(atom)
store.set(atom, value)
}
}
}Option 2If an atom is a resettable atom and a reset call is completed, then remove it from the hydratedSet. export const hydratedMap: WeakMap<Store, WeakSet<AnyWritableAtom>> = new WeakMap()Update the export function useResetAtom(
anAtom: WritableAtom<unknown, [typeof RESET], unknown>,
options?: Options
) {
const setAtom = useSetAtom(anAtom, options)
const resetAtom = useCallback(() => {
options?.clearHydrate && hydratedMap.delete(anAtom)
return setAtom(RESET), [setAtom]
})
return resetAtom
}I can implement the solution if we believe either Option is liked 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I'm seeing upvotes, so I'm going to take it as we are good to proceed. I'll approach both options and see what's cleaner code if there is no preference. |
Beta Was this translation helpful? Give feedback.
-
|
I think I'm going to go with Option 2. |
Beta Was this translation helpful? Give feedback.
-
|
This scenario is well described. I agree that it is common, it can be taken as a basic 'cache invalidation' which we often want to do after a flow (like form submit) is finished. But since the options flag |
Beta Was this translation helpful? Give feedback.
-
|
Here is a working example: #669 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
FYI - I opened a PR to optionally support re-hydration: #1990 |
Beta Was this translation helpful? Give feedback.
-
|
Hey @SariSabouh do you have some example on how to use the options flag? I struggle to imagine some clean solution on how would I toggle flag on/off. But based on what would I get the |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your question, @MiroslavPetrik ! We used it as follow: const [atomValue, setAtomValue] = useAtom(
myAtom
)
useHydrateAtoms(
[[myAtom, { ...myAtomSSRValues, initialized: true }]],
{
dangerouslyForceHydrate: myAtom.initialized === false,
}
)This solved our use case flawlessly with minimum modifications. |
Beta Was this translation helpful? Give feedback.
-
|
How does that work? So you are always using the default behavior, and never the options flag? |
Beta Was this translation helpful? Give feedback.
-
|
In other words, this is the flow that the component takes:
|
Beta Was this translation helpful? Give feedback.
-
|
related: #2337 |
Beta Was this translation helpful? Give feedback.
-
Greetings!
I've been playing around with the new hook
useHydrateAtomsthanks @Thisen! really excited that we've started to experiment with how best to support ssr use cases for jotai.I've personally ran into some interesting limitations, and I'm curious what every thinks about how we can work to support this, or at least provide some best practices. I've constructed a very small next.js app that fetches some data from hacker news.
The app is structured with some very specific requirements that I request we do not try to change in order to make this hook work, but instead think about how we can adjust the hook or way the hook is used such that it can support these requirements.
App overview
Click here for the app homepage (with
useHydrateAtoms)Click here for the app homepage + Provider (with
Provider)There are a few atoms:
postsAtom(contains all posts, without comments)currentPostIdAtom(contains the current query param if exists)currentPostDataAtom(contains the data with comments for the current post)There are a few pages:
/index.tsx(home)/[id].tsx(id)/provider/index.tsx(same as home, but withProvider)/provider/[id].tsx(same as above, but withProvider)Scenario
The way the app works is that the initial data will fetch for all posts when a user lands on the home page, and hydrate
postsAtom. When a user clicks on one of the links to a post page, the application will fetch data for that page and "hydrate" the atoms with the correct data:currentPostIdAtomandcurrentPageDataAtom.The issue occurs when a user wants to navigate to an adjacent page from the current page. When the user clicks the link, the URL updates, but none of the data updates. The reason this happens is because the
useHydrateAtomshook has a limitation in place where it tracks which atoms have been hydrated, and if they have been, to not re-hydrate them.Provider example
You can navigate to the
/providerpath and find the same app, but using theProviderto set the initial values for the atoms. Something to note:keyis used on theProviderto force a re-render when the postId changes. This results in the correct functionality when a user navigates from page to page.Best practices and open questions
When working with this, I find myself asking the question: "Should
useHydrateAtomsmake the choice to prevent duplicate hydrations?".I don't know the answer to it, I can see why it makes sense to want to prevent atoms from being hydrated more than once, and how much of a can of worms it could be to try and provide a mechanism to prevent abuse of this.
On the other hand, I think it would also make sense to try and be as generic as possible when it comes to this hook, and let app devs/users handle when and how they hydrate a given atom.
client side updates
Something I've considered is maybe we need to let the app dev just use
useAtomoruseUpdateAtomand write a hook that will update the atom on the client, anduseHydrateAtomswon't ever touch any client side updates (as it is intended for SSR hydration).I've played around with it a bit, and find that it just doesn't feel ideal. Of course we can do this, and suggest this as an option, but I think we can probably find something better:
This feels like it can get out of hand very quickly, especially as complexity grows.
Alternatives and initial ideas
I think there are some options that jump out to me immediately as things we can explore:
Remove the limitation
We could simply remove the limitation from
useHydrateAtomsand provide guidance on how the values will update if they change/re-render.Provide a callback
Currently the hook is what is doing the hydration, but I think something like this could be helpful:
This gives more control to app devs and gives them an ability to determine when and how things are hydrated.
Provide some new hook
Perhaps there is a hook we haven't thought of yet that can provide a great developer experience. I'd love to hear any ideas around this!
Do nothing
Or maybe this is the best / intended functionality, and we should recommend other methods for handling this kind of scenario.
How do other libraries handle it?
To be honest, there are only a few libraries that really have taken great time and care to solve this for users. React Query is one of those libraries, and I think we can take a page out of their book about prioritizing developer experience. From their docs on hydration:
This method does indeed support hydrating on the client side, in which case the data will be merged with the existing data.
Summary
Thanks for reading this far! I hope that by starting this discussion, we'll be able to work though possible solutions or ideas for how to move forward with something like this!
Beta Was this translation helpful? Give feedback.
All reactions