It would be helpful if Atom writers could determine if they were called within useHydrateAtoms

[akkadaska]

Thank you for developing this wonderful library and providing such extensive support.

Issue

When using Jotai with Next.js, I often find myself wanting to change the behavior of Atom writers based on whether they're being called within useHydrateAtoms. I'd like to present a case where this would be useful and discuss whether there are existing workarounds or if it would be valuable to add this functionality to Jotai.

Here's an example of an Atom with a side effect that updates another Atom to maintain the state of being changed when the original Atom is modified by the user (not by useHydrateAtoms):

const isChangedAtom = atom(false);
const baseAtom = atom<string>('hello');
const derivedAtomWithEffect = atom<string, [update: string], void>(
  (get) => get(baseAtom),
  (_get, set, update) => {
    set(baseAtom, update);
    set(isChangedAtom, true); // this is the side effect
  },
);

Hydration works correctly in this case:

useHydrateAtoms([
    [derivedAtomWithEffect, 'Initial Content from Server'],
    [isChangedAtom, false],
  ]);

However, hydration doesn't work as expected in these cases:

useHydrateAtoms([
    [derivedAtomWithEffect, 'Initial Content from Server'],
  ]);
// or
useHydrateAtoms([
    [isChangedAtom, false],
    [derivedAtomWithEffect, 'Initial Content from Server'],
  ]);

These results reflect the current implementation of useHydrateAtoms:

• If isChangedAtom is not included in the hydration, it gets updated to true during the side effect of derivedAtomWithEffect, so its initial value becomes true.
• If isChangedAtom is included in the hydration, whichever operation is processed first (the hydration of isChangedAtom itself or the side effect of derivedAtomWithEffect) determines the value of isChangedAtom.

As we can see, when an Atom has side effects on write, the only way to ignore these side effects during hydration is to rely on the order of the array in useHydrateAtoms.

This issue can also occur in other scenarios, such as:

• On a search page, where changing any condition always triggers a side effect to return to the first page, but during hydration, we want to set the value specified on the server-side.

Note:

A quick solution could be to set the baseAtom during hydration. While this works, it's not always applicable because such requirements are common, and we often create wrappers that don't allow external access to the equivalent of baseAtom, like this:

// define
export function atomWithSideEffects<Value, Args extends unknown[], Result>(
  initialValue: Value,
  writeWithDependencies: WriteWithDependencies<Value, Args, Result>,
) {
  const self = atom<Value>(initialValue);

  return atom<Value, Args, Result>(
    (get) => get(self),
    (get, set, ...args) => writeWithDependencies(get, set, self, ...args),
  );
}

// use
const atomWithEffect = atomWithSideEffects<string, [update: string], void>(
  '',
  (_get, set, self, update) => {
    set(self, update);
    set(isChangedAtom, true); // this is the side effect
  },
);

Ideas

Since hydration is a special event different from others, it would be helpful if the Writer could detect it. This would allow us to change the Writer's behavior during hydration, solving the above problem.

Here are a couple of ideas:

Idea 1: Add isHydrating to the Writer's arguments

If we could add isHydrating to the Writer's arguments, we could write something like this:

const derivedAtomWithEffect = atom<
  string,
  [update: string, isHydration: boolean],
  void
>(
  (get) => get(baseAtom),
  (_get, set, update, isHydration) => {
    set(baseAtom, update);
    !isHydration && set(isChangedAtom, true); // this is the side effect
  },
);

However, at least in Jotai v2.9.1, this causes a type error with useHydrateAtoms:

// Causes "no overload matches" error but should be fine
useHydrateAtoms([
  [derivedAtomWithEffect, 'Initial Content from Server', true],
]);

Idea 2: jotai/utils library provides an Atom that is true only during hydration

If the jotai/utils library could provide an isHydratingAtom that's set to true at the start of useHydrateAtoms implementation and false at the end, we could write:

const derivedAtomWithEffect = atom<string, [update: string], void>(
  (get) => get(baseAtom),
  (get, set, update) => {
    set(baseAtom, update);
    get(isHydratingAtom) || set(isChangedAtom, true); // this is the side effect
  },
);

Conclusion

As mentioned above, the need to determine whether a call is made within useHydrateAtoms often arises when using Jotai. I'd like to discuss whether there are existing workarounds for these cases or if it would be valuable to add this functionality to Jotai.

Thank you for your consideration.

[dai-shi]

Thanks for opening up a discussion.

I don't feel like adding anything in the core for this as there's no notion about hydrating. (btw, AFAIR, useHydrateAtoms only accepted base atoms in v1.)

How about this?

useHydrateAtoms([
  [derivedAtomWithEffect, 'Initial Content from Server'],
  [doneHydrationAtom, true],
]);

[dai-shi]

useHydrateAtoms is fragile anyway, like if you can hydrate the same atom twice, but the second will be ignored without warning. If useHydrateAtoms is used multiple times, we don't know the order, it just depends on React scheduling.

So, to support SSR frameworks, we may need a completely new solution. We basically need Provider with SSR, so SSRCapableProvider component might be an option.

We created useHydrateAtoms without understanding the real SSR use cases, and SSR frameworks weren't that popular then. It's time to overhaul.

The doneHydrationAtom needs to be placed at the end of the array to ensure it's set after all other atoms have been hydrated.

Yeah, the order is important. useHydrateAtoms([...], doneHydrationAtom) might mitigate it, but I don't think it's ideal.

---

If someone has ideas, I can help if needed, but it has to be a community package like jotai-ssr. If that goes successful, I'm happy to transfer useHydrateAtoms to it from jotai/utils.

[akkadaska]

Thank you for your detailed explanation. I now understand the complexities surrounding useHydrateAtoms and the need to rethink SSR-related functionalities in Jotai.

I'm currently working on a large-scale Next.js application using Jotai, which has given me practical insights into these SSR challenges. Given this experience, I'm considering creating a jotai-ssr-like library in my personal repository. Once I have a working prototype, I'd be happy to share it here for your review. I hope it could serve as a useful reference for addressing these SSR-specific needs.

Thank you very much for your support.

[akkadaska]

I opened a new discussion about new utility to enhance SSR support.
I would appreciate it if you could review and provide feedback.
#2692

[akkadaska]

New jotai-ssr lib was released and it support this feature.
https://www.npmjs.com/package/jotai-ssr