How to handle deeply recursive state

[IanDuncanson]

Just wondering the best way to handle not just nested but potentially recursively nested state in jotai?

I have set up a code sandbox to help illustrate the question - code here .

The important construct to model is the IComponent interface -

interface IComponent {
  type: string;
  id: string;
  properties?: Record<string, unknown>;
  content?: IComponent[];
}

We have an editing environment that would allow you to add components to another component, and potentially edit the properties of any component anywhere in the component hierarchy via a property grid. So, in the interface above, the "properties" prop and the "content" prop are both able to be edited.

I was wondering if the best way to handle this to minimize re-rendering would be to normalize this state to something like the following -

interface INormalizedComponent {
  type: string;
  id: string;
  properties?: Record<string, unknown>;
  content?: string[];
}

where the content prop is now just an array of references to other component ids. And then the jotai representation of a component would be something like -

type ContentAtom = Atom<string[]>;
type PropsAtom = Atom<Record<string, unknown>>;
interface INormalizedComponentAtom {
    id: string;
    type: string;
    properties: PropsAtom;
    content: ContentAtom;
} 
type NormalizedComponentAtom = Atom<INormalizedComponentAtom >;

And then finally, store the NormalizedComponentAtom's in either an atomFamily or even just a simple WeakMap (since I don't really need to track updates to the full component list anywhere - except maybe for undo/redo)

[dai-shi]

I'm not sure if there's single best way for it.
I would prefer atoms in atom model without normalizing, but normalized approach would be a nice one too.

[IanDuncanson]

@dai-shi - I am a bit confused how atoms in atoms model works to be honest, and how it would allow us to keep re-rendering to a minimum (for example, how to not re-render the entire component tree if you add a new component to the top level/root parent), I guess unless we pass atoms around as props, which we have avoided doing until now. Is you suggestion that we model as such -

type PropsAtom = Atom<Record<string, unknown>>;
type ContentAtomAtoms = Atom<ComponentAtom[]>;

interface IComponentAtom {
    id: string;
    type: string;
    properties: PropsAtom;
    content: ContentAtomAtoms;
} 

All the examples of atoms in atoms in the documentation tend to be a single level deep (i.e. an array of atoms in an atom or a map of atoms in an atom) , not recursive, and not based on dynamic arrays and maps as we have, where the arrays or maps are changed dynamically.

Do you know of any github repositories that are using Jotai extensively for real world implementations? Maybe if you had a list of projects that highlight the usage of Jotai it would be easier to understand for people like me, only new to atomic state management

[IanDuncanson]

@dai-shi, I have had an attempt at an atoms within atoms approach using this sandbox.

It mostly works, although I am seeing some extra renders of child components. I have added why-did-you-render to the sandbox, and it seems to be because of this line of code in my ComponentLoader component - (line 117 of App.tsx)

const resolvedContent = useAtomValue(content ?? atom(null));

why-did-you-render is saying this is "different objects that are equal by value". Is there any chance you could take a look and explain why this is causing a re-render of all the child components when a new component is added by clicking the buttons on the left? I presume it is because the atom value in this case is an atom itself, which is a function, so the function is different each time, but I am not sure how you would stop this

[dai-shi]

- const resolvedContent = useAtomValue(content ?? atom(null));
+ const stableNullAtom = useMemo(() => atom(null), []);
+ const resolvedContent = useAtomValue(content ?? stableNullAtom);

Or define it outside render.

[dai-shi]

I am a bit confused how atoms in atoms model works to be honest

Assuming you read the docs, take a look at the ToDo example.
https://github.com/pmndrs/jotai/tree/main/examples/todos

export type PropsAtom = PrimitiveAtom<Record<string, unknown>>;

That's not atoms in atom. It's like

export type PropAtoms = Record<string, PrimitiveAtom<unknown>>;

[IanDuncanson]

The reason I had it the original way is that "props" is just a javascript object typed as Record<string,unknown>, and that props object can have both keys added to it and values changed (and if anything changes in the object, either a prop is added to the object by extending it, or a value of an existing prop is changed, I will need to re-render the component). In other words, the value of a prop in the props object is only serialized and deserialized to the PropsAtom if it is different to the "defaultValue" of that prop in the component. Hope that makes sense.

Anyway, as always, really appreciate not just the brilliant work you have done with all your libraries and the sharing of them, but your fantastically responsive help.

[dai-shi]

Yeah, I probably didn't get the original intention.
Hope the todo example helps.
Please note that I'm not pushing hard on atom-in-atom pattern for your use case. It's just one idea out of many.

[IanDuncanson]

Yep, fully understand. Tree type/recursive state is one of the harder use cases, and different libraries have had different approaches to handling it (Redux suggests normalization, Mobx has gone a different direction by providing specific libraries like mobx-state-tree and mobx-keystone to handle deeply nested state, hookstate has specific constructs just for nested state).

I might still go the normalization route, maybe using atomFamily or even a simple Map of ids to ComponentAtoms, only because it allows me to not pass atoms around as props, I can use the ids, which we already pass as a key and are globally unique, but it was still a good learning experience