Looking for a useRecoilState_TRANSITION_SUPPORT_UNSTABLE equivalent: first load suspends - rest use transition

[neil-morrison44]

Hi,

Not sure if I've missed this in the docs but I can't find an equivalent to useRecoilState_TRANSITION_SUPPORT_UNSTABLE.

I'm looking for something which suspends on first load (unlike loadable, unwrap etc) then every subsequent load A) doesn't suspend and B) starts a React transition.

I've got this, which seems to work, but the promise bits are awkward (and probably not robust) & I'm wondering if I've missed a trick somewhere.

export const useSmoothedAtom = <T>(
  atom: WritableAtom<Promise<T>, [T], Promise<void>>
) => {
  const store = useStore()
  const [firstProm] = useState(() => store.get(atom))
  const value = use(firstProm)
  const [state, setState] = useState<T>(value)

  useEffect(() => {
    store.sub(atom, async () => {
      const value = await store.get(atom)
      startTransition(() => setState(value))
    })
  }, [store, atom])

  const setThing = useSetAtom(atom)
  return [state, setThing] as const
}

[dai-shi]

Have you tried using useTransition simply?

[neil-morrison44]

When setting the value?

I've got quite a big graph of atoms & some of the ones at the root level are atomWithRefresh with effects that refresh them every X minutes so the change doesn't begin within the React tree.

Also if there's multiple layers of async atom (which there is) I think it falls afoul of this startTransition limitation: https://react.dev/reference/react/startTransition#:~:text=You%20must%20wrap%20any%20state%20updates%20after%20any%20async%20requests%20in%20another%20startTransition%20to%20mark%20them%20as%20Transitions.%20This%20is%20a%20known%20limitation%20that%20we%20will%20fix%20in%20the%20future%20(see%20Troubleshooting).

[dai-shi]

the change doesn't begin within the React tree.

Ah, then startTransition would probably be required. Yes, we need to wrap everything that triggers updates. So, your workaround would be reasonable, if you would like to avoid the ceremony.

[sebinsua]

I'm looking for something which suspends on first load (unlike loadable, unwrap etc) then every subsequent load A) doesn't suspend and B) starts a React transition.

@neil-morrison44 Thank you for posting an interesting code snippet.

I think the problem (and UI pattern) you're describing is the same as the one I'm solving in withSwr (#3044) but from a different perspective.

I was trying to solve the problem at the Jotai data layer by cleanly switching atom behaviour from async to sync after the initial load, while you are trying to use React's built-in support for transitions to render new states in the background on subsequent updates instead of displaying loading states. Sort of a data-layer vs view-layer approach?

Unfortunately, my workplace is still using legacy React renders, so I haven't looked into how transitions could be used in this way, but is it fair to say that this mainly makes sense when the "cause" of a transition is a user interaction in your application, and not something like a background call to an atomWithRefresh? I'm also wondering how this works when there's a fairly complicated interplay between different async atoms being updated in the background indirectly via user interaction and Jotai effects, etc. Does React reliably suppress fallbacks?

[neil-morrison44]

Yeah, I tend to think of this as a view-layer thing to keep my data layer cleaner (and there's some parts of the UI which might use atoms derived from the same tree wherein I do actually want to show a loading state).

The graph of my atoms (in this example) is pretty complex - there's things subscribed to outside events, user interactions, things which refresh every couple of minutes - so any given derived atom could have multiple reasons for updating.

The snippet seems to resolve the issue of going back into Suspense after the initial render, however I remain unsure about it's robustness & would prefer something more core in Jotai which resolves it at the point of atom use (ideally something as easy to use as loadable but I haven't thought much about the feasibility of that)

[dmaskasky]

so any given derived atom could have multiple reasons for updating.

jotai/vanilla/internals has a way of listening to atom updates now.

import {
  INTERNAL_getBuildingBlocksRev1 as INTERNAL_getBuildingBlocks,
  INTERNAL_initializeStoreHooks as initializeStoreHooks,
} from 'jotai/vanilla/internals'

const store = createStore()

const buildingBlocks = INTERNAL_getBuildingBlocks(store)
const storeHooks = initializeStoreHooks(buildingBlocks[6])
// first arg is undefined to listen to _all_ atom changes on the store.
const removeCallback = storeHooks.c.add(undefined, function atomOnUpdate() {
  // count updated
})