"Mid-level" state atoms?

[davewasmer]

Imagine an image editor component. It's a complex component that encapsulates lots of other components, and ideally presents a simple interface.

Inside the <ImageEditor>, I'd like to use Jotai atoms to manage state. However, I don't want to couple the <ImageEditor> component to some global atom used elsewhere in my app:

import { currentImageAtom } from 'cool-app/atoms';

// ⛔️ Don't want to do this, because it tightly couples this generic component to my global state
function ImageEditor() {
  let image = useAtom(currentImageAtom)

So I'll take the image I want to edit as a prop:

// ✅ Nice! Reusable, decoupled, looks good
function ImageEditor(props: { image: Image }) {

But now all my other internal components need to reference this image prop, ideally via atoms.

What's the best way to approach this?

My first take: "sync" the prop to a "local" atom:

const imageBeingEdited = atom<Image | null>(null);

function ImageEditor(props) {
  let [image, setImage] = useAtom(imageBeingEdited);
  useEffect(() => {
    setImage(props.image)
  }, [props.image]);

But now all my other derived atoms need to have null checks everywhere, despite the fact that they will never be used in the real-world without an image present:

function ImageCropper() {
  let [image] = useAtom(imageBeingEdited);
  // ⛔️ image is now typed as `Image | null` despite it not really being possible to be null

Basically, I want to have "mid-level" atoms. I.e. atoms that are not really global state, but also not purely local to a single component. Curious if anyone has any good patterns for this.

[dai-shi]

Jotai is designed to cover such use cases.
Basically, you don't need to define atoms globally.

const ParentComponent = ({ foo }) => {
  const fooAtom = useMemo(() => atom(foo), [foo]))
  // ...
}

Now, the question is how to pass fooAtom to child components.

Option 1: props

const ChildComponent = ({ fooAtom }) => {
  const [foo, setFoo] = useAtom(fooAtom)
  // ...
}

const ParentComponent = ({ foo }) => {
  const fooAtom = useMemo(() => atom(foo), [foo]))
  return <ChildComponent fooAtom={fooAtom} />
}

Option 2: context

const FooAtomContext = createContext()

const ChildComponent = () => {
  const fooAtom = useContext(FooAtomContext)
  const [foo, setFoo] = useAtom(fooAtom)
  // ...
}

const ParentComponent = ({ foo, children }) => {
  const fooAtom = useMemo(() => atom(foo), [foo]))
  return (
    <FooAtomContext.Provider value={fooAtom}>
      {children}
    < /FooAtomContext>
  )
}

Option 3: atom-in-atom with scoped provider

This is an alternative pattern to option2 only with jotai. Provider scope is almost equivalent to creating a new context.

const FooScope = Symbol()
const fooAtomAtom = atom(null)

const ChildComponent = () => {
  const [fooAtom] = useAtom(fooAtomAtom, FooScope)
  const [foo, setFoo] = useAtom(fooAtom)
  // ...
}

const ParentComponent = ({ foo, children }) => {
  return (
    <Provider initialValues={[fooAtomAtom, atom(foo)]} scope={FooScope}>
      {children}
    < /Provider>
  )
}

---

Another pattern still to be explored: provider with globally defined atoms

This is still a new pattern to explore, but sometimes we want to define atoms outside so that defining derived atoms is easier.

const fooAtom = atom(0)
const doubledFooAtom = atom((get) => get(fooAtom) * 2)

const ChildComponent = () => {
  const [foo, setFoo] = useAtom(fooAtom)
  const [doubledFooAtom] = useAtom(doubledFooAtom)
  // ...
}

const ParentComponent = ({ foo, children }) => {
  return (
    <Provider initialValues={[fooAtom, foo]}>
      {children}
    < /Provider>
  )
}

Provider will isolate atom values from other providers (or non-provider). So, this is limited to some use cases.
If we need to follow the change of foo from parent, we need useEffect to update the value with setFoo(foo) in Provider, which is tricky.

---

Hm, now I re-read your description, and I actually wonder what I described is relevant. Let's see..
Two take-aways:

1. atoms can be defined in a component with useMemo.
2. Provider may help scoping atom values.

[davewasmer]

Thanks for the quick response @dai-shi! Insightful ideas here.

I'm still wrapping my head around the Provider approach, but for useMemo: wouldn't the end result be the same as just props, both for performance and ergonomics?

Vanilla props approach

function ParentComponent(props) {
  return (
    <ChildComponent foo={props.foo} />
  )
}
// `foo` gets passed down every level manually via props
function ChildComponent(props) {
  return (
    <NestedChildComponent foo={props.foo} />
  )
}

Performance: 👎 re-render the whole tree for every change in props.foo
Ergonomics: 👎 prop drill props.foo all the way down to any deeply nested consumers

useMemo + atom

function ParentComponent(props) {
  let fooAtom = useMemo(() => atom(props.foo), [props.foo]);
  return (
    <ChildComponent fooAtom={fooAtom} />
  )
}
function ChildComponent(props) {
  let foo = useAtom(props.fooAtom);
  return (
    <NestedChildComponent foo={foo} />
  )
}

Performance: 👎 changing props.foo still results in a whole-tree re-render, since we create a new atom whenever it changes
Ergonomics: 👎 don't have to prop drill foo all the way down, but you do have to prop drill the fooAtom all the way down

---

Normally the core aspect I love about Jotai is that it gets you Context-like ease of use, with optimized re-render performance - just import whatever atom of state you need, nothing else required. Here though, there might be other value that Jotai brings to the table here, but feels like the core comparison is essentially the same as using vanilla props or context?

[davewasmer]

Thinking as I type here ...

Part of the ease of Jotai et al here is that we get to use static, module-scope object identities to reference state. No need to pass around handles, references, selectors - just import { fooAtom }. We get to "hop outside" the React tree to reference our state.

Part of my mental mismatch is that my component can't really use a static, module scope atom, since there might be multiple instances of my generic component, which conflicts with the singleton-style module scoped atom.

It's almost like I want a state bucket that is tied to the component lifecycle, i.e.:

function ParentComponent(props) {
  // Creates an atom that is a stable reference for the lifetime of the component instance
  let fooAtom = useMemo(() => atom(props.foo), []);
  let [foo, setFoo] = useAtom(fooAtom);
  // Now copy any future state changes into that same stable atom reference
  useEffect(() => setFoo(props.foo), [props.foo]);

  return (
    // Now, fooAtom is stable even when props.foo updates, so ChildComponent won't be forced to re-render every time props.foo changes
    <ChildComponent fooAtom={fooAtom} />
  );
}

function ChildComponent(props) {
  // Now, ChildComponent _will_ re-render every time foo changes, but _only_ because it actually opts-in to using foo, not simply because the atom reference itself changed every time
  let [foo] = useAtom(props.fooAtom);
}

Does ⬆️ make any sense?

[dai-shi]

for useMemo: wouldn't the end result be the same as just props, both for performance and ergonomics?

No. Performance is better if you use {children} or React.memo.

Part of my mental mismatch is that my component can't really use a static, module scope atom, since there might be multiple instances of my generic component, which conflicts with the singleton-style module scoped atom.

If we use <Provider>, module scope atom works. There's still something to explore, though.
The basic example is this: https://twitter.com/dai_shi/status/1447892237753278466

[davewasmer]

Finally got around to digging into the <Provider> approach, and it clicked. The scope prop is such an elegant solution for this! Great solution to solve exactly what my problem is.