handling contextual state like auth

[joprice]

I'm curious about approaches for handling state that is discovered at runtime, like a user session: It is initially undefined, but for atoms that deal with displaying user details or making use of the user session, it is effectively required. Say there are several atoms that manage data synced to a local cache, which is fetched using an api client, that in turn depends on a user session. Is AtomProvider the best approach here, where everything that requires session directly or indirectly takes these as atom instance parameters ?

[bowheart]

Hey @joprice. Normally, I'd say this isn't something you'd have to think about. Components lazily initialize atoms as they're mounted. You wouldn't typically render a <UserName /> component, for example, until the user is logged in.

I'm not sure I'm following this part:

Say there are several atoms that manage data synced to a local cache, which is fetched using an api client, that in turn depends on a user session

Some (pseudo-)code would be helpful. But I'm imagining this basic setup for now:

const userDataAtom = atom('userData', undefined) // populated later

const getUserName = ({ get }: AtomGetters) => get(userDataAtom)?.name

function UserName() {
  const userName = useAtomSelector(getUserName)

  return userName == null ? null : <span>{userName}</span>
}

The pain point with this setup that I think you're pointing out here:

it is effectively required

is having to deal with undefined. There are a few ways to go about it. Using an AtomProvider like you said would work, though that might get very involved passing atom instances around.

If you really are guaranteeing that the data is defined when it's used in certain places, then a wrapper atom like this would be my preferred approach:

const loadedUserDataAtom = ion('loadedUserData', ({ get }) => {
  const userData = get(userDataAtom)

  if (!userData) {
    throw new Error('tried accessing user data before it was loaded')
  }

  return userData
})

Now consumers of loadedUserDataAtom will either throw the error, signaling to you that you broke your guarantee, or will know that the data is always defined:

// TS knows there's no need for `?.`:
const getUserName = ({ get }: AtomGetters) => get(loadedUserDataAtom).name

function UserName() {
  const userName = useAtomSelector(getUserName)

  // and no need for `== null` check:
  return <span>{userName}</span>
}

There may be more approaches, but let me know if I'm going in the wrong direction here.

[joprice]

Yes that's exactly the situation I was thinking of. With other approaches to state that don't attempt to represent the graph statically, I'd have some sort of "AuthGate" that ensures the nullability is handled at runtime, then from there on out the data is accessed through a non-nullable variable stored in context. For a single value like auth, it's easy enough to add the runtime check you suggested, but if you have four or five dependencies that should all be in a certain state before using them, it becomes cumbersome and error-prone. Even with a single runtime dependency like in the auth example above, I had issues where logging out caused display of errors in components that assumed the user was non-nullable. (This could have been something subtle with contexts and react native navigation, but it's not something I've had happen since I switched to passing a non-nullable reference downward since the types rule out that case).

What I'd like in general is to have a sub-graph of atoms to be "unlocked" by a "key", similar to a object-capabilities model or how subsets of a graphql schema require parameters to access. I'm now starting to see that context is the way to go since this is a runtime verification. Just trying to figure out what I should be taking care of and what Zedux should handle. I like Zedux since it has most everything baked in that you normally have to piece together with multiple libraries, and especially that the data layer is testable outside of the UI, so I was attempting to see if I could fit the full runtime state into the static graph. I think I'll try out an approach where the base atoms are parameterized, and then provided via AtomProvider, along with some helpers to make usage simple and see how it turns out.

[bowheart]

Is there a reason you need to clear the atom (e.g. security concerns, or you just want to fully control atoms outside React)? Normally you'd give it ttl: 0 to allow it to die when no longer in use. With that, when the parent unmounts the component subtree containing all usages of the atom, the atom is automatically destroyed.

If that's too simple a use case, there are a few things:

1. Basically your idea, creating an intermediary atom, selector, injector, or hook that holds onto the last non-nullish value. Here's an example we use for animations in our codebase:

import {
  AnyAtomInstance,
  AnyAtomTemplate,
  AtomParamsType,
  AtomStateType,
  ParamlessTemplate,
  useAtomValue,
  ZeduxHookConfig,
} from '@zedux/react';
import { useRef } from 'react';

/**
 * Returns the last non-nullish value of the provided atom to allow exit animations to finish
 * without blanking out the data in the view
 */
export const useLatchingAtomValue: {
  <A extends AnyAtomTemplate>(
    atom: A,
    params: AtomParamsType<A>,
    config?: ZeduxHookConfig
  ): AtomStateType<A>;
  <A extends AnyAtomTemplate>(atom: ParamlessTemplate<A>): AtomStateType<A>;
  <I extends AnyAtomInstance>(instance: I, params?: [], config?: ZeduxHookConfig): AtomStateType<I>;
} = <A extends AnyAtomTemplate>(
  atom: A | AnyAtomInstance,
  params?: AtomParamsType<A>,
  config?: ZeduxHookConfig
) => {
  const value = useAtomValue(atom as A, params as AtomParamsType<A>, config);
  const latchedValue = useRef(value);

  // we latch onto the old value if the value is now undefined or null
  if (value != null) {
    latchedValue.current = value;
  }

  return latchedValue.current;
};

(Hah, React compiler would complain about that now that I look at it. But that ref assignment would be fine in practice).

2. Zedux gives you a lot of control over order of events. You can use a promise or observable for ttl that prevents the atom from being destroyed until a parent component unmounts. Note that this doesn't destroy anything unless the atom goes stale (has no dependents). Example using the new Promise.withResolvers():

const logoutNotifierAtom = atom('logoutNotifier', () => Promise.withResolvers())

const userAtom = atom('user', () => {
  const { promise } = injectAtomValue(logoutNotifierAtom)

  return api(fetchUser()).setTtl(promise)
})

function TopLevelAuthedComponent() {
  const { resolve } = useAtomValue(logoutNotifierAtom)

  useEffect(() => {
    return () => resolve()
  }, [])
}

Though, if you need to clear the atom's state, I would have expected a top-level component like this to be where you clear it. If it needs to be cleared by another atom or some child deeper in the tree, you can still wait for the top-level component to unmount before clearing, something like this:

const userAtom = atom('user', () => {
  const { get } = injectAtomGetters()
  const { store } = injectPromise(fetchUser, [])

  const clear = async () => {
    await get(logoutNotifierAtom).promise

    store.setState(state => ({ ...state, data: undefined }))
  }

  return api(store).setExports({ clear })
})

[joprice]

These are great solutions. I do need to run some actions to clear user data and close db sessions, so I want some kind of guarantee that it's done at least before the app closes. I haven't tried out ttls yet, so not sure how they behave.

I think I'll need to play around with them to see which works as I'll likely need to retain the state for the exit animation case as well. I'll try it out tomorrow and provide any feedback.

[joprice]

I just got this working using the "placeholder" approach with a helper like this (not exactly the same as I'm actually calling this from a Fable Fsharp wrapper I wrote):

const ignoreEmptyAtom  = (name, target)  =>
        atom(name, () => {
            const value = injectAtomValue(target);
            const current = injectStore(value);
            injectEffect(() => {
                if (value) {
                    current.setState(value);
                }
            }, [value]);
            const state = current.getState()
            if (!state) {
                throw new Error("Attempted to access atom before initial value was set");
            };
            return state
        });

const nullableAtom = atom("user", undefined)
const nonNull = ignoreEmptyAtom(nullableAtom)

[bowheart]

@joprice Cool! A few things:

• The injectEffect shouldn't be necessary there, unless you specifically want to wait a tick
• I'd always return the store, not the store's state, from the state factory. Zedux will create another, different store for this atom instance if you don't.

const ignoreEmptyAtom  = (name, target)  =>
    atom(name, () => {
        const value = injectAtomValue(target);
        const current = injectStore(value);
        if (value) {
            current.setState(value);
        }
        if (!current.getState()) {
            throw new Error("Attempted to access atom before initial value was set");
        };
        return current
    });

[joprice]

I actually put the setState in an effect because I thought it was necessary, but good to know. I remember seeing something in the docs about inline effects that mentioned the later notes in the suspense docs, but never resolved it in my mind of what exactly are the rules for inline effects. So essentially, you can think of the atom's body as being an effect block that's triggering based on dependencies, and injectEffect is only strictly necessary when the call should always be made at some future time. And the setState will be done synchronously before the end of the atom function, so not cause two "events" to be emitted from that atom downstream?

Returning the store makes more sense now that you point that out. I think i had just already dereferenced the state so just returned what I had at hand.

[bowheart]

the setState will be done synchronously before the end of the atom function, so not cause two "events" to be emitted from that atom downstream?

Yes. In your case, dependents would have only been notified once anyway, since the state isn't changed until the effect runs, but yes, updating state inline can prevent dependents from being notified multiple times unnecessarily.

Zedux specifically prevents state updates on injected stores during atom evaluation from triggering another evaluation. You should still use an effect if updating state in an injected atom instance. Though in that case, you should also try to avoid the effect by e.g. using an export to update the upstream atom's state directly rather than waiting for the effect to run. The principle is the same as React's "you might not need an effect" doc.

you can think of the atom's body as being an effect block that's triggering based on dependencies

Yes, you can treat atoms this way, though I'd only do this with specific types of atoms. For example, the docs treat query atoms this way, which works because query atoms are typically very focused on one goal: Fetching/updating one piece of data.

Atoms with less clear objectives or lots of injectors (that can use other injectors, etc) where every injector is making this assumption could get unruly.

In either case, effects are still useful for making sure a side effect only runs in a subset of the cases that could have triggered the current atom to reevaluate. But that usually won't apply when you're just forwarding an upstream state change on to an injected store.

[joprice]

That makes sense. I think I've muddled changes to parameters vs injections in my mind. I've been using the analogy of "subscribing" to changes in react props by using an effect to update local state when a prop changes, but parameters produce different atom instances in zedux. I think I need to write some tests with some injected values that change and see if I get a better feel for when the effect body is run and when an effect is actually needed in derived atoms. I'll probably hit more concrete cases to motivate it as I migrate more code over as well.