How to disable atom cache?

[devnomic]

So its quite hard for me to describe, but what i want is very simple, similar like react context.
i just need similar good old useState(initialValue), but the state/setState i can access from any component.

I think it related to #127.

i also don't want to use init function, as i am using remix/react-router 7, since it use ssr on first hit, so the data is available immediately on first render. (if i create init function, i need to use useEffect to load and re-render from empty to filled which i don't want to).

but i can't do it since if zedux atom key is same, it will not trigger injectStore again. so i kind of need { cache: false } config.

i can use random value likeMath.random() for the second params of useAtomInstance which i think it will works as i intended, but it obviously not the best way since i will end up in many unused instances.

is this possible on zedux? @bowheart
i think it's more similar with jotai atom of what i want to achieve, since they don't use key? i haven't try jotai again.

import {
  atom,
  AtomProvider,
  injectStore,
  useAtomContext,
  useAtomInstance,
  useAtomValue,
} from "@zedux/react";
import type { ReactNode } from "react";
import type { ProjectSettings } from "~/types/db";

export const settingsAtom = atom(
  "projectSettings",
  (initFn: () => ProjectSettings) => {
    const store = injectStore(initFn());
    return store;
  },
);

export function SettingsProvider({
  children,
  settings: initialSettings,
}: {
  children: ReactNode;
  settings: ProjectSettings;
}) {
  // pass the initial settings as function to avoid getting hashed
  const settingsInstance = useAtomInstance(settingsAtom, [
    () =>  initialSettings,
  ]);

  return <AtomProvider instance={settingsInstance}>{children}</AtomProvider>;
}

export function useSettingsFunctions() {
  const instance = useAtomContext(settingsAtom, true);

  return { setValues: instance.setStateDeep };
}

export function useSettings() {
  const instance = useAtomContext(settingsAtom, true);
  return useAtomValue(instance);
}

Consume

export default function Project({ loaderData }: Route.ComponentProps) {
  const { project,  settings } = loaderData;

  return (
    <SettingsProvider settings={settings}>
        <div className="w-full">
          <ProjectHeader />
          <ProjectMain />
        </div>
    </SettingsProvider>
  );
}

function ProjectMain() {
   const { setValues } = useSettingsFunction();
   return <button onClick={()=> setValues({ hello: 'world' })}>Click</button>
}

React context equivalent. works as intended, but suffer from frequent update like slider update value.

import { createContext, useContext, useState, type ReactNode } from "react";
import type { ProjectSettings } from "~/types/db";

export interface SettingsContext {
  settings: ProjectSettings;
  setSettings: (value: ProjectSettings) => void;
}

const SettingsContext = createContext<SettingsContext | null>(null);

export function SettingsProvider({
  children,
  settings: initialSettings,
}: {
  children: ReactNode;
  settings: ProjectSettings;
}) {
  const [settings, setSettings] = useState(initialSettings);

  const contextValue = {
    settings,
    setSettings,
  };

  return (
    <SettingsContext.Provider value={contextValue}>
      {children}
    </SettingsContext.Provider>
  );
}

export function useSettings() {
  const context = useContext(SettingsContext);
  if (!context) {
    throw new Error("useSettings must be used within a SettingsProvider.");
  }

  return context;
}

[bowheart]

jotai-scope has this. And we could add an atom(s) prop to AtomProvider that works similarly. I don't usually like APIs that don't give the provider access to the thing it's providing, but maybe it could be a useful shorthand.

But yes, Zedux can do it using a unique id param (I wouldn't use Math.random).

An early prototype of Zedux had "Local Atoms" that were instantiated every time they were used - you had to share the atom instance reference to avoid creating extra instances. We got rid of them because they:

• aren't a common use case
• are too different from how atoms normally work
• can be done with normal atoms

Anyway, here's how:

const settingsAtom = atom('projectSettings', (_id: string) => {
  const store = injectStore(hydration => createStore(null, hydration), {
    hydrate: true,
  })

  return store
}, { ttl: 0 }) // <- EDIT: I'd definitely add this

function SettingsProvider({
  children,
  settings: initialSettings,
}: {
  children: ReactNode,
  settings: ProjectSettings,
}) {
  // initialize a new settingsAtom every time this component mounts
  const id = useId()
  const ecosystem = useEcosystem()
  const settingsInstance = useMemo(() => {
    // set up initial state before instantiating:
    ecosystem.hydrate({
      [settingsAtom.getInstanceId(ecosystem, [id])]: initialSettings,
    })

    // now create a new instance for this component:
    return ecosystem.getInstance(settingsAtom, [id])
  }, [ecosystem, id]) // snapshot initialSettings - don't pass as dep

  return <AtomProvider instance={settingsInstance}>{children}</AtomProvider>
}

[bowheart]

Awesome! Thanks. I see what's happening. When using useEffect, the flicker is due to Remix hydrating the page with outdated values. Those values get outdated because the Zedux ecosystem on the server is caching them the first time any page loads. Nothing ever updates them since useEffect doesn't run on the server.

The flicker goes away with useMemo because that does run on the server, updating the server ecosystem's cached atom. But it introduces a new problem on the client - React will log this error:

Cannot update a component (`SomeDeepNestedDisplay`) while rendering a different component (`SettingsProvider`)

Jotai's dangerouslyForceHydrate would trigger this too, but I want to avoid it.

Going back to useEffect, this was my expectation:

At worst, I'd expect to see a tiny state tear on rehydrate due to React updating the directly-rendered id here:

<div>Project ID: {id}</div>

one tick before the useEffect causes SomeDeepNestedDisplay to rerender. Even that tear (wouldn't be a perceptible a flicker in this case) would probably go away when using useLayoutEffect.

However, it looks like my expectation was wrong. On navigate, React is rerendering in the background and doesn't commit until the useEffect runs (tested by CPU hogging for two seconds in the effect. There's no tearing). In short, there's no difference between useEffect and useLayoutEffect here. They both work.

The Fix

On the server, hydrate retroactively during render.

On the client, hydrate non-retroactively during render and then hydrate retroactively in useEffect.

function useHydrateAtomInstance<A extends AnyAtomTemplate>(
  template: A,
  initial: AtomStateType<A>
) {
  const ecosystem = useEcosystem();

  // hydrate retroactively on server, safely on client
  ecosystem.hydrate({ [template.key]: initial }, { retroactive: typeof window === 'undefined' });

  useEffect(() => {
    // now update cached atoms on client
    ecosystem.hydrate({ [template.key]: initial });
  }, [ecosystem, initial]);

  const instance = useAtomInstance(template);

  return instance;
}

Looks like this works in your example. Let me know if you find anything else.

The Other Fix

The reason I haven't run into this is I reset the server's ecosystem on every request. I've also seen people create a new ecosystem for each route on the server. Your example is using Zedux's global ecosystem in all cases, keeping every atom cached across routes. That explains why others haven't run into this.

The simple fix: Wrap the route in an <EcosystemProvider> and make sure useHydrateAtomInstance is called inside that. That will create a new ecosystem with no cached atoms every time the server renders a new route.

I understand all this is not really documented - the SSR guide in the docs is too low level. I'm planning a new, much more useful guide for SSR with a framework. Will hopefully get to it soon.

This was very helpful for me. I hadn't dug into a Remix project before or a setup exactly like this. Thanks again @devnomic.

[devnomic]

Hi, thanks for your reply again.

I can’t believe I missed that error log, I thought everything was working fine. but frankly there is no issue on ui page.

The fix using useEffect does work, but it causes a flashing issue.
Imagine a scenario where I have a long list displayed on a project page.

Here’s the flow:

• A user navigates from Project A page (which shows a list), back to the dashboard page.
• Then from dashboard page, they go to Project B page (which should show a different list).
• When the Project B page is opened, the list from Project A is still displayed (stale data) until useEffect kicks in and updates the page to show the Project B list. This creates a poor user experience.

I also tried using EcosystemProvider, but it didn’t work and there are no Route component in Remix anymore by default.
so i tried to put inside root.tsx however it throws error.

export default function App({ loaderData }: Route.ComponentProps) {
  return (
    <EcosystemProvider>
      <Outlet />
    </EcosystemProvider>
  );
}

Zedux: useAtomContext - No atom instance was provided for atom "settingsMediaBackgroundMusicUrl".

ReferenceError: Zedux: useAtomContext - No atom instance was provided for atom "settingsMediaBackgroundMusicUrl".

Any idea how to solve

Edit:
i found this (will try playing around with this later to check how they work)
https://www.npmjs.com/package/jotai-ssr#re-hydration

[bowheart]

The fix using useEffect does work, but it causes a flashing issue.
Imagine a scenario where I have a long list displayed on a project page.

Ah, so this flashing problem I do understand. This is the nature of the beast when dealing with caching. When multiple views reuse the same types of data, you have to determine whether they should:

• reuse the same exact data (for example, user data/preferences/settings/themes usually fall in this category)
• populate new data with the same shape (your example of different data for the same list falls in this category)

In atom terminology, this means figuring out whether each atom is a singleton or a multiton (aka atom family). In Zedux terminology, it means determining if each atom has params (and/or scope in v2).

It sounds like your Project B page is trying to reuse singletons from the Project A page that should have been atom families.

// Example fix: Add a `projectId` param:
const projectListAtom = atom('projectList', (projectId: string) => ...)

// Then each project page gets its own atom instance:
const projectList = useAtomValue(projectListAtom, [projectId]) // where projectId is provided to the whole project page

Using atom families allows for even better UX since both Project A's and Project B's lists can be cached at the same time. Users can go back and forth between them without having to reload either list. You can use a non-zero ttl to destroy data for each list after they've been unused for a while

// Example: Destroy after being unused for 5 minutes:
const projectListAtom = atom('projectList', (projectId: string) => ..., { ttl: 3e5 })

I also tried using EcosystemProvider, but it didn’t work and there are no Route component in Remix anymore by default.
so i tried to put inside root.tsx however it throws error.

Oh I see, so I believe in root.tsx, it'll wrap both the server and client in the <EcosystemProvider>. Only the server should create new ecosystems. The client's should stay cached. This should do:

return (
  <EcosystemProvider id={typeof window === 'undefined' ? undefined : 'root'}>
    <Outlet />
  </EcosystemProvider>
)

[devnomic]

Unfortunately even using "atom family"/param id also have issues with this kind of framework that handle the ssr and data fetching. That's why i actually doesn't need the caching, just need simple global atom with get atom and set atom globally with initial value.

Here is the issues even with param:

1. If we are using useEffect, even though we are passing projectId as params id, there will a flashes from empty list to real list for the first load (we lose advantage of SSR providing initial data).

2. Now imagine if the project page is some kind of an image or video editor page, which have Save button.
   The flows:

• User open project A and play around with it (adjust text/change color, etc -> which is local state), but decided not to save. (but already cached by zedux).
• User goes back to dashboard.
• User goes back again to project A, zedux state automatically show the last time state, then it flashes from unsaved state to state from server database. At least it is what i observe in the real code that i am working right now. This issue doesn't happen when using useMemo hydrate hook, but react will log error like you mentioned earlier.

I tried this on my real project, but it logs the same error.

return (
  <EcosystemProvider id={typeof window === 'undefined' ? undefined : 'root'}>
    <Outlet />
  </EcosystemProvider>
)

So i tried playing around with jotai-ssr, it almost perfect like using useMemo hook earlier but have flash issues on rehydration.

• init atom value on initial ssr ✅ works
• rehydrate atom value on soft navigation (flashes from current value to initial value first ❌, before the value shown correctly from server). ideally flashes from current value to value from server.

here is if you want to take a look, maybe you could help to solve this with zedux, but without all the jotai-ssr and useMemo issues, because you obviously know a lot better how these works behind the scenes than me:
https://codesandbox.io/p/devbox/29pn9f
(click set a value, then click next link to see the rehydration flashes)

jotai ssr code:
https://github.com/jotaijs/jotai-ssr/blob/main/src/hydrate-atoms/use-hydrate-atoms.ts

[bowheart]

I'll dig into the differences. Upfront, I see Jotai SSR is doing this:

hydrate everything immediately on first render, then never again

useEffect -> hydrateRetroactively

Slightly different from my approach:

hydrate all atoms that haven't been initialized yet immediately on every render

useEffect -> hydrateRetroactively

I like mine better.

It looks like you're just triggering an extra useEffect run in your jotai-ssr example. React Router triggers an extra render of the top-level Projects component before routing. I don't know why, that seems like a bug to me. To work around it, I think all you'd need to do is memoize the hydrateAtoms array:

const hydrateAtoms = useMemo(() => [[settingsAtom, initial]], [initial])
...
<HydrationBoundary hydrateAtoms={hydrateAtoms}>

For Zedux, I don't see that flash at all using the approach I already posted. Sandbox here: https://codesandbox.io/p/devbox/zedux-rr7-forked-p9tvlt