Assessing options for handling propagation of changes in deeply nested state tree

[dbstraight]

Imagine you have a deeply nested state tree. Leaf models in the tree are passed as props to React components using observer. Changes in one of these leaves may require updates to distant parts of the tree. What should you do?

Option 1: Make the root available everywhere

If the root is globally available, we can just call an action on the root or drill down to where we need to call an action.

• Pros: Very simple to implement, explicit behavior
• Cons: Testing the leaves (model or component) requires construction of an entire tree, leaves may need to know about very unrelated parts of the tree (less modular), root may need a very large number of actions ("god class")

Option 2: Use getParent to walk up the tree

In many ways, this is not materially different from option 1. Leaves still need to know about the broader context in which they are used which causes loss of modularity / testability.

Option 3: Use volatile state to store event handler functions

Something like this:

interface Volatile {
    handleValueChange?: (previous: number, current: number) => void,
}
export const Model = types.model("Model", {
    value: 42,
}).volatile(
    () => ({} as Volatile)
).actions(self => ({
    changeValue(next: number) {
        const previous = self.value;
        self.value = next;
        if (self.handleValueChange) {
            self.handleValueChange(previous, self.value);
        }
    }
}));

Now parents that contain a Model as a child can register an event handler by setting the value of the volatile handleValueChange.

• Pros: Explicit "hook" for when parent has a chance to apply changes elsewhere, does not require the child to know what other changes need made, does not require global root, easy to test
• Cons: In order to make these events "bubble", they will have to be handled and reraised at every level of tree (basically the same event bubbling / prop drilling problem that you get in React), some events may need a pre (with opportunity to cancel) and post (react to change) which is extra clutter

Option 4: Use MobX reactivity (such as autorun or reaction)

Like this:

Parent.actions(self => ({
    afterCreate(): void {
        reaction(() => self.child, child => {
            self.handleChildChange(child);
        });
    },
}));

• Pros: No need to configure anything on the child to allow for reacting to changes
• Cons: Have to dispose of reaction when appropriate, don't get an exact "description" of what changed (for example, if you're watching for changes to an array, your reaction will fire but you won't know if an item was added, removed, internally modified, etc.)

Option 5: Use onAction

This works similarly to reaction, but with some trade-offs:

• Pros (compared to reaction): You get a path to what change was made
• Cons (compared to reaction): You have to manually intepret / walk that path to get to the change since the path is just a string

And so we come to option 6... Middleware!

Middleware seems to be able to handle all of this pretty elegantly (or overcomplicatedly depending on your perspective I guess).

import { addMiddleware, Instance, types } from "mobx-state-tree";

export const Child = types.model("Child", {
    value: 0,
}).actions(self => ({
    setValue(value: number) {
        self.value = value;
    }
}));
export type ChildInstance = Instance<typeof Child>;

export const Parent = types.model("Parent", {
    children: types.array(Child),
}).actions(self => ({
    setChildValue(index: number, value: number) {
        self.children[index].value = value;
    },
})).actions(self => ({
    afterCreate() {
        // If any of the children find the answer to life, the universe, and
        // everything, pass that knowledge along to all children
        addMiddleware(self, (call, next, _abort) => {
            if (Child.is(call.context) && call.name === "setValue") {
                // We can lean on TypeScript in many ways to make this safer...
                const [ value ] = call.args as Parameters<ChildInstance["setValue"]>;
                if (value === 42) {
                    for (let i = 0; i < self.children.length; i++) {
                        self.setChildValue(i, 42);
                    }
                }
            }
            next(call);
        });
    }
}));

• Pros: No need to configure child in any way, parent gets direct access to all information on the action, easy to test, automatically bubbles, allows aborting actions
• Cons: More code, needs some TypeScript fanciness to be fully type safe (but it can be made fully type safe which is great), you have to make extra actions on the parent (because the middleware handler isn't an action, it can't directly mutate any state, and if you tried to just child.setValue in the handler, you would cause infinite recursion), may be confusing to understanding how it works

---

I'm happy to provide additional information / code / sandboxes if needed, but I tried to keep this as concise as possible. I'm hoping to have a discussion and see what other people think about these various choices, maybe find some consensus on the best way to handle this kind of updating disparate parts of a deep tree. I couldn't find anything in the docs or other discussions that dealt with this problem in this way, so I'm not sure if this is crazy and abusing middleware or actually a good idea.

I'm immensely grateful for anyone who has read all this and offers a reply. 🙇

[coolsoftwaretyler]

Hey @dbstraight - just wanted to say I've seen this, I don't have an clear thoughts yet, but I don't want this to go unacknowledged. I will put some more thought into it.

FWIW, I have basically tried all of these except volatile event handlers, with varying degrees of success. I agree with most of your pros/cons, but don't have a better set of thoughts to provide.

[coolsoftwaretyler]

Hi @dbstraight - I took some time to sleep on this, reflect, and put together my thoughts. I'm a current maintainer of MobX-State-Tree, but I hope anyone reading this will interpret this comment as personal opinions based on my own experience. I am not ready to declare any of these the "official" recommendation. Apologies if someone is looking for an official answer, but I'm just not comfortable drawing a line in the sand. That said, I hope my thoughts are helpful to you and others:

Can we improve our data model to avoid this issue?

Changes in one of these leaves may require updates to distant parts of the tree. What should you do?

To start, I think this is a yellow flag that we can model our data better. A handful of these scenarios is usually unavoidable, but if you have so many of these scenarios, I think there's an underlying modeling problem.

However, I understand many of us work on existing codebases where we can't make changes to the fundamental data model of our state management layer. So it's a good exercise to answer the rest of your question. I just wanted to address the root issue which is: can we avoid having leaf nodes interact with other parts of the tree? That would be a holistic answer to this.

But if it's impossible or undesirable to change the tree structure, here's some thoughts about your proposed solution:

Make the root available everywhere

This is basically how I do it in my day-to-day work. I think it's maximally flexible, and if a component wants multiple leaves, even if those leaves don't interact with one another, I can pull them from the root directly.

I've experienced the cons you mentioned - testing can be hard. But if you take some time to write a good tree factory, that can improve your test suite overall anyways. I think solving the testing problems in this approach will improve your testing strategy.

However, one con you can't avoid is the "god class" scenario. Again, if you need more than a handful of those god-level actions, I think an abstraction has been missed. But at the end of the day, it makes a lot of conceptual senes for me for the "root" to be able to kind of reach down wherever it wants and do stuff. Sure, "god classes" are undesirable. But if there's going to be one anyways, why not make it the root of the state tree?

Use getParent

One advantage you didn't discuss here was that getParent is easier to mock or stub out in tests. You can side-step reconstructing a whole tree in testing, and return narrower trees.

I think getParent can be clunky (it's still so strange to me that it throws an error when there is none, but other users have told me they like this). Another sharp edge is if you're using the depth argument and your tree structure changes. It can be annoying to hunt it down.

When I have taken this approach, I often wrap the getParent call in a helper view on the leaf node. But hey, sometimes child nodes need to know stuff about parent nodes. That's valid, IMO.

Volatile state

I've never even considered this, but I kind of like it! I really like the way this decouples leaf nodes from parent actions. It does seem like it could get tricky to figure out correct bubbling and order-of-operations.

I bet someone who was very good at event-driven programming would have some interesting thoughts around this. I am no expert on that, myself, but I think this approach warrants more consideration and writing. I'm going to personally do some thinking around it. Not sure what I want to do about it, other than lend credence to the thought. Very cool!

MobX Reactivity

This makes sense, but every time MST users have to "drop down" into MobX land, I consider that a failing of MST. In our docs, we say that you don't need to know anything about MobX to use MST, and I hope to be able to live up to that.

Still, I think this is perfectly valid. I just hope that we can provide better answers than this. I would not recommend this, except for folks who are already MobX users and feel very comfortable with it.

onAction

This is definitely a good use for that hook, but as you say, it requires a good amount of understanding of how MST paths work to be useful. And it suffers from similar issues as getParent, where if your paths change, you have a bunch of dependent code that needs to change as well.

I think I prefer this over the MobX approach, but in a similar way, it's a good way to start understanding what's going on in your tree. If it weren't for Middleware (next section), I'd find this quite compelling as well.

Middleware

Middleware is awesome. I think that's preceisely what middleware was designed for. I like to reach for middlewares when I end up in a state where none of the above make sense. It's pretty easy to test, or avoid testing. But you're right, the typings can be kind of weird, and if you have enough of these scenarios that you have a bunch of middlewares, the routing ends up getting kind of gnarly, and you can try to smooth it over with a function, but at some point, you really just need a big if statement or switch statement to figure out which middlewares do what.

I also think there's a sharp edge on middlewares: since they're always running, if you introduce some non-performant code at the entrypoint, you might slow down your whole app.

My recommendation

Again, my actual recommendation is: try to model your data such that you rarely need to think about it. But if you need any of these solutions, they're all pretty great!

But if I was forced to make my recommendation in order of highest preference to lowest preference:

1. Root node everywhere: the root of your tree is basically the god class anyway, so use it as such and make it available everywhere. This makes everything straightforward to write, and the downsides are mostly test related. Be careful of tight coupling, but that's always good advice anyway.
2. Middlewares: If you don't want a god class, consider middlewares (but hey... isn't that just like a demigod?). IMO, they're a great way to bridge any inconsistencies or troubles in your data modeling. If MST doesn't fit your use case perfectly, middlewares are a good escape hatch to course correct.
3. getParent: getParent would be item 2 if I didn't hate the error handling so much. I just don't like having to try...catch because I wanted to get my node's parent. But that's neither here nor there. It's a personal preference. Other than that, getParent is part of the API, and I encourage folks to use it when it makes sense.
4. Volatile: onAction should actually probably win here since I think it's more intended for this use case than volatile, but... I think this is so cool.
5. onAction: I think the other approaches will give you similar results for less work. But onAction is also part of the API for a reason. Could be very helpful.
6. MobX Reactivity: we owe a great deal to MobX. I think this is a perfectly valid approach. But MST is a library intended to abstract away the details of MobX, so I don't want to recommend people re-introduce MobX concepts to their MST codebase where there are viable alternatives directly from the MST API. Still, this is perfectly reasonable.

[jamonholmgren]

I agree with Tyler's approach. I also like "root node everywhere" and that's what we do at Infinite Red.

[dbstraight]

I really appreciate all the information. This is very helpful.

I wish I could come up with a good simplified example of the kind of state updates I'm thinking about without having to try to explain my entire app. I'm definitely going to look at other ways to model the data, but I don't think there's any getting around these kind of distant updates.

Anyway, I posted originally just trying to show the middleware option as "vanilla" as possible but I think TS can do a lot of heavy lifting to make it much more ergonomic, so I want to share that too. Basically I've got this helper function:

import { IAnyType, Instance, IMiddlewareHandler } from "mobx-state-tree";

export type ChildMiddlewareHandler<
    TChild extends IAnyType,
    TAction extends keyof Instance<TChild>
> = (
    child: Instance<TChild>,
    ...args: Parameters<Instance<TChild>[TAction]>
) => ReturnType<Instance<TChild>[TAction]> | undefined;
export const handle = <TChild extends IAnyType, TAction extends keyof Instance<TChild>>(
    Child: TChild,
    action: TAction,
    handler: ChildMiddlewareHandler<TChild, TAction>,
    after: boolean = false
): IMiddlewareHandler => (call, next, abort) => {
    if (Child.is(call.context) &&
        action === call.name &&
        (
            call.parentId === 0 ||
            call.parentActionEvent?.context === call.context
        )) {
        if (after) {
            next(call);
        }
        const result = handler(
            call.context,
            ...call.args as Parameters<Instance<TChild>[TAction]>
        );
        if (result !== undefined) {
            abort(result);
            return;
        }
        if (after) {
            return;
        }
    }
    next(call);
};

So when you go to use this on Parent, what it would actually look like (instead of the above) is:

export const Parent = types.model("Parent", {
    children: types.array(Child),
}).actions(self => ({
    handleChildSetValue(_child: Instance<typeof Child>, value: number) {
        if (value === 42) {
            for (let i = 0; i < self.children.length; i++) {
                self.children[i].setValue(42);
            }
        }
    },
})).actions(self => ({
    afterCreate() {
        const middleware = handle(Child, "setValue", self.handleChildSetValue);
        addMiddleware(self, middleware);
    }
}));

And TS will ensure (VS Code will even suggest for you) that "setValue" is actually a member of Child and that the type signature of handleChildSetValue is correct. This starts to look a lot more like registering event handlers, just on events that are never explicitly defined anywhere. This gives us the ability to have an ancestor watch for certain kinds of child events that it knows have impact elsewhere in the system and then propagate those without the children ever knowing it's happening.

I'll try to come back with some examples of the types of situations where these updates happening because maybe I'm missing something at the modeling layer that would solve this.

[coolsoftwaretyler]

Nice, @dbstraight! I also really like using the afterCreate hook to set up the Middleware. For a while I was attaching middleware outside of lifecycle events, just in my store file, and I ran into order-of-operations problems during testing, but I think your approach is sound.

And for what it's worth, for both you and anyone else who may find this - I totally understand sometimes these distant state updates become necessary. If you can design your way around them, that's great, but sometimes the real world can't be nicely modeled by our software systems, and that's precisely where these mechanisms like middleware and the rest we've discussed come into play.

I'm going to mark this thread as "resolved" with your follow up, but I encourage folks to contribute more to the discussion with opposing or augmented viewpoints here.

Thanks, all!