promises, suspense, and changing params

[joprice]

When using an atom that wraps a promise along with suspense, Is is possible to trigger suspension when props passed to the atom as args change? Or is this a case where suspend: false should be used? In other words, is suspense only triggered on the first load (and an invalidation?) of any atom.

I saw a relevant comment here

zedux/packages/react/test/snippets/suspense2.mdx

Line 40 in c1e075a

console.log('starting transition')

React transitions don't apply to suspense. But if they ever do, this will be cool which seems to imply that I should use my own loading code making use of PromiseState when I care about subsequent re-loads showing the loader.

[bowheart]

Hey @joprice. Components using any atom hooks will re-suspend when the atom's .promise reference changes.

const suspendingAtom = atom('suspending', () => {
  // quick example that changes the promise reference every time this atom reevaluates:
  return api().setPromise(new Promise(resolve => setTimeout(() => resolve('test'), 1000))))
})

function ExampleComponent() {
  const suspendingInstance = useAtomInstance(suspendingAtom)

  return <button onClick={() => suspendingInstance.invalidate()}>Re-suspend</button>
}

function ExampleSuspenseWrapper() {
  return (
    <Suspense fallback={<div>ExampleComponent suspending...</div>}>
      <ExampleComponent />
    <Suspense>
  )
}

Note that you can use injectMemo or injectPromise to prevent the promise reference from changing every evaluation, which is usually what you want.

Is it possible to trigger suspension when props passed to the atom as args change?

This should also "just work" to re-suspend the component, but in this case, it'll be because the different params create an entirely new atom instance.

function ExampleComponent() {
  const [counter, setCounter] = useState(0)
  // creates a new atom instance every time `counter` changes.
  const suspendingInstance = useAtomInstance(suspendingAtom, [counter])

  return <button onClick={() => setCounter(state => state + 1)}>Re-suspend</button>
}

(an example like this should be paired with ttl to prevent creating tons of dead atom instances).

Transitions are completely different from suspense. It doesn't sound like you're referring to transitions (via useTransition) here (tell me if I'm wrong). Transitions are a pretty half-baked React feature right now and are especially poor for 3rd-party state managers, though Zedux works around some of the difficulties to provide at least the best possible transition support. But again, I don't think that's what you're looking for.

[bowheart]

Awesome! Yep, runOnInvalidate was what I was going to suggest.

Sorry I was slow responding last week. I'm back to normal this week.

[joprice]

I'm hitting one more broad issue with error handling: When a transient error like network a blip that bubbles up to an ErrorBoundary higher up in the tree, outside of the context where the original atom that caused it, it's not clear what is meant to be invalidated to get it to retry, as there is not necessarily an association with the error and the atom. Calling resetErrorBoundary will trigger a re-render, but end up reusing the failed promise, so no new http call is made. ecosystem.reset can be used to reset everything, but if there are expensive data loads that happen on app start, that causes unnecessary overhead for retrying a single transient error.

A few ideas I had:

• use a custom error subclass to attach a field that has the atom or an id attached, and then walk the error's cause chain, in case the exception was rethrown.
• use the ecosystem to filter for atom's in failed states (using PromiseState) to invalidate them
• wrap the access to the atom in a catch block that invalidates and rethrows the error, so it's auto-invalidated on failure. I'm not sure this will account for transitive invalidation, if an atom depends on another that was the root cause, does that inner one need to be invalidated?

Any thoughts on how to approach this?

[joprice]

I tried out the second one and it works, currently checking for atom's with non-null _promiseError and invalidating them. I guess I could also check for Active lifecycle status as well but not sure the implications of that.

[bowheart]

The first bullet was my first thought. I don't think I see a problem with it.

The second bullet is a cool idea. I'm not sure if I would have thought of that. It's really good if you don't mind globally searching all atoms. You could filter for specific ones that are "globally invalidatable" e.g. with specific atom key prefixes or using atom flags to narrow that search.

I think I have a general suggestion for you. Atoms in Zedux are very autonomous. They're great at handling operations by themselves, without requiring consumers to do anything imperative. My general approach thinking about this problem is, "Okay, this atom threw an error. How can he set himself up to retry the operation?"

Whether that retry is automatic or happens on button click or some other event, the atom that errored should be setting up the retry, not any of its transitive dependents or any React components.

So following that line of thinking, I have this (roughly coded) solution:

const retriesAtom = atom('retries', () => {
  const store = injectStore<(() => any)[]>([]) // a list of functions to run on retry

  const addRetry = (fn: () => any) => store.setState(state => [...state, fn])

  const retryAll = () => {
    for (const fn of store.getState()) {
      fn()
    }

    store.setState([])
  }

  return api(store).setExports({ addRetry, retryAll })
})

const maybeFailingAtom = ion('maybeFailing', ({ getInstance }) => {
  const self = injectSelf()

  const promise = injectPromise(
    () => maybeFetchSomething().catch(
      // this atom sets itself up for retry:
      () => getInstance(retriesAtom).exports.addRetry(() => self.invalidate())
    ),
    [],
    { runOnInvalidate: true }
  )

  return api(promise)
})

function ErrorBoundaryWrapper() {
  const retriesInstance = useAtomInstance(retriesAtom)

  return (
    <ErrorBoundary
      FallbackComponent={MyFallbackComponent}
      onReset={() => {
        retriesInstance.exports.retryAll()
      }}
    >
      <ComponentSubtreeThatUsesMaybeFailingAtom />
    </ErrorBoundary>
  )
}

Hopefully that helps with approaching problems like this in Zedux. Your first bullet pretty much does this, just having the atom throw a particular, smart error instead of using a separate retriesAtom. Your second bullet does too, actually, discreetly flagging atoms as "retryable" based on their _promiseStatus (or _promiseError, sure), though, again, I feel like that's too global and could end up flagging atoms that it shouldn't.

Watch out for underscore-prefixed properties btw. Lots of those will change in v2. I'll always try to show how to update all of them in version migration notes, so watch for those. These _promise* properties will probably change.

[joprice]

This is a great suggestion. It is less global, opt in, and explicit. Plus, I was already wary about relying on the internals with the promise state. I'll prototype this in my codebase and see If I hit any issues with it. Thanks again!