-
|
First, I'd like to express my gratitude for the development of this fantastic library. This library supports SSR through the Problems1. Need for proper Provider setup in Next.js
|
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 19 replies
-
|
Thanks for opening up a discussion.
So, it's a new problem. You don't have such issues with Pages Router, right?
Interesting. I wasn't aware such a behavior. That sounds tricky.
I'm not sure if I follow every details, but it seems like a good step.
As I said, we don't consider this as the Jotai core feature. It's an integrations like other integrations. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for replying.
Yes, this is a new problem related to App Router (and React Server Component).
I'm ready for creating for |
Beta Was this translation helpful? Give feedback.
-
|
Sent an invitation! |
Beta Was this translation helpful? Give feedback.
-
|
New Please give us a feedback! |
Beta Was this translation helpful? Give feedback.
-
|
I realized that when using 'use client'
import { atom } from 'jotai';
export const someAtom = atom(0);This requirement exists because when
Jotai atoms include functions. To paraphrase the above quote, functions or atoms that are exported from client-marked modules can be passed from a React Server Component to a React Client Component. Therefore, adding the At least this approach works in Next.js App Router. However, I'm not sure if adding the |
Beta Was this translation helpful? Give feedback.
-
|
I think it's reasonable and necessary to add |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! I have thought about this thoroughly and concluded that this is the optimal approach. Since Jotai's Atom checks identity by reference, we need to pass it as a prop from a React Server Component to a React Client Component. (Tanstack Query's HydrationBoundary can do this because the identifier, QueryKey, is serializable, which does not apply to Jotai.) I will update README. |
Beta Was this translation helpful? Give feedback.
-
|
I had a misunderstanding about why However, even with the correct understanding, this library, including MisunderstandingMy incorrect understanding was as follows:
In reality, since navigation using the The mismatch between HTML and hydration was a known issue:
This issue can also be resolved by using New ProblemWith client-side navigation using the The following is an issue when trying to share Jotai's Store at the A Next.js project reproducing these issues can be found here: Problem with
|
Beta Was this translation helpful? Give feedback.
-
Don't worry. We need iterations. I actually wonder if the hydration error is Next.js specific. |
Beta Was this translation helpful? Give feedback.
-
|
The same issue occurred in Remix with the Additionally, I discovered a new Remix-specific issue when using slugs or URL path parameters and navigating to another slug with the I believe that this issue is not limited to Next.js but may also affect Remix and other frameworks that support client-side navigation of page components with server-side rendering. |
Beta Was this translation helpful? Give feedback.
-
|
Can you make a reproduction with Waku? That will help me understand the problem. |
Beta Was this translation helpful? Give feedback.
-
|
Reproduction with Waku: https://github.com/akkadaska/jotai-waku-link-navigation When the Jotai store is defined in the root layout and shared between pages using the navigation
Additionally, a Waku-specific error not encountered with Next.js and Remix occurs:
Finally, an issue unrelated to Jotai occurs when importing modules containing the
|
Beta Was this translation helpful? Give feedback.
-
Conclusion of Jotai with Next.js, Remix and WakuWith slug pages
Using Jotai Provider defined in Root Layout component and shared by pages
|
Beta Was this translation helpful? Give feedback.
-
|
I think I understand at least one miscommunication. Here's the modified example: https://stackblitz.com/edit/github-dfyxta?file=src%2Fcomponents%2FRootLayoutWrapper.tsx,src%2Fpages%2F_layout.tsx,src%2Fcomponents%2Fuse-hydrate-atom.tsx |
Beta Was this translation helpful? Give feedback.
-
|
Current my idea of when atoms should be set (still under consideration)
RB: RenderingBoundary, HB: HydrationBoundary |
Beta Was this translation helpful? Give feedback.
-
|
I believe this is the ideal way to set an Atom. @dai-shi , I am planning to implement jotai-ssr to support this approach. I would greatly appreciate it if you could share your thoughts on this. Rules and Atom Set TimingRules
|
| Timing | Within Isolated RB | Within Upper Ref RB |
|---|---|---|
| SSR (Direct Navigation) | Initial Render | Initial Render |
| Client-side Navigation | Initial Render | Effect |
| Re-render-HB | Effect | Effect |
| Mount-HB after navigation | Initial Render | Initial Render |
RB: RenderingBoundary, HB: HydrationBoundary
SSR (Direct Navigation)
Jotai atoms are used within Client Components. Client Components are SSR-rendered during direct navigation, where the entire root layout is rendered.
Within Isolated RB
If RenderingBoundary does not specify useUpperStore, an independent store is generated for each Layout and Page component. Only one HydrationBoundary is present to hydrate a given atom within this isolated RenderingBoundary. Therefore, the atom is hydrated before being referenced, making it safe to set the atom values during the initial render.
Even if RenderingBoundary specifies useUpperStore, rendering during SSR is performed from the root layout. As long as each independent RenderingBoundary contains only one HydrationBoundary, setting atom values during the initial render is safe.
Client-side Navigation
During client-side navigation, only the required parts are re-rendered, and the upper RenderingBoundary might not be remounted.
Within Isolated RenderingBoundary
If RenderingBoundary has its own independent store, the RenderingBoundary and HydrationBoundary of the new page are newly mounted. The atom is not yet referenced anywhere, so setting atom values during the initial render is safe.
Within a RenderingBoundary Referencing the Upper Store
If RenderingBoundary references the upper store via useUpperStore, the atom might already be referenced by other components. React rules prohibit updating existing state (atom values) during render, so you need to use useEffect to set the values.
In particular, for Next.js App Router, if you navigate to the same page component by changing the path parameter (slug), the entire page (RenderingBoundary) will be newly mounted. If atom values are set during the initial render of this new page, the previous page will re-render. In this case, you need to set the atom values using useEffect.
Re-render-HB
When a HydrationBoundary is re-rendered, atom values must be set again. However, updating values during render when the atom is already referenced violates React’s rules, so you should use useEffect to set the values.
Specifically, in frameworks like Remix or Waku, if you navigate to the same page component by changing the path parameter (slug), the entire page (RenderingBoundary) will not be remounted. Instead, re-rendering will occur due to the change in props. In this case, you need to use useEffect to set the atom values.
Mount-HB after Navigation
When a new HydrationBoundary is mounted after navigation, atom values can be set during the initial render because they are not yet referenced.
Conclusion
By properly using RenderingBoundary and HydrationBoundary and implementing them according to the rules above, atom values can be set optimally for any type of rendering, including SSR.
Beta Was this translation helpful? Give feedback.
-
|
Not sure every detail, but I think I get the overall idea. I'm curious how |
Beta Was this translation helpful? Give feedback.
-
|
Without Indeed, I don't know how much this option needed. I will reconsider, |
Beta Was this translation helpful? Give feedback.
-
|
After developing with Jotai in Next.js App Router, I realized that among the cases I thought needed consideration, only a small subset is actually used in practice. For other cases, instead of implementing complex handling logic within the library, it is more practical to provide comprehensive documentation so users can follow the appropriate rules when implementing. Based on these reflections, I have revamped the features provided by the
|
Beta Was this translation helpful? Give feedback.
-
That sounds like a bug. I wonder if we can create a minimal reproduction. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I found a perfect solution in my case no need for "use client";
import { useStore, atom } from "jotai";
import { ReactNode, useSyncExternalStore } from "react";
const dataTableAtom = atom<{ [key: string]: any }>({});
export function DataTableProvider(props: {
children: ReactNode;
data?: DataTableStores;
}) {
const store = useStore();
const dataToHydrate = props.data || {};
useMemo(() => {
try {
const existing = store.get(dataTableAtom);
if (
props.data &&
JSON.stringify(existing) !== JSON.stringify(props.data)
) {
store.set(dataTableAtom, dataToHydrate);
}
} catch {
store.set(dataTableAtom, dataToHydrate);
}
}, [store, props.data, dataToHydrate]);
useSyncExternalStore(
(callback) => store.sub(dataTableAtom, callback),
() => store.get(dataTableAtom) ?? dataToHydrate,
() => dataToHydrate,
);
return <>{props.children}</>;
} |
Beta Was this translation helpful? Give feedback.
New
jotai-ssrlib was released!https://www.npmjs.com/package/jotai-ssr
Please give us a feedback!