References: getting a user's todos

[mossymaker]

I want to understand why MST handles references in a way that's different from what I expected (and, possibly, what's advertised), and is that a limitation, bug, or user error.

In the docs, MST describes identifiers and references:

References and identifiers are a first-class concept in MST. This makes it possible to declare references and keep the data normalized in the background, while you interact with it in a denormalized manner

The docs stop short of showing something like a User having a one-to-many relationship with something like a Todo, so I put together a demo based on one of the examples to try to better understand that setup. Here are the important bits:

const Todo = types.model("Todo", {
  id: types.identifier,
  title: types.string,
  finished: false,
  user: types.maybe(types.reference(types.late(() => User))),
})

const User = types.model("User", {
  id: types.identifier,
  name: "",
  todos: types.array(
    types.safeReference(
      types.late(() => Todo),
      { acceptsUndefined: false }
    )
  ),
})

const TodoStore = types.model("TodoStore", {
  todos: types.array(Todo),
  users: types.array(User),
})

My expectation was that if there's a list of users and a list of todos, when a todo that refers to a user (e.g. an assignee) is added to todos, that user's reference to the list of todos would be updated such that the user's todos could be found with user.todos, but it was empty.

Puzzled, I looked for relevant discussions...#1953 maybe touches on this? I took one of the replies to mean that I'd have to update the user's todos reference when adding a todo item. In my demo, that's:

const TodoStore = types
// ...
.actions((self) => ({
  addTodo(title, _user) {
    const id =
      self.todos
        .map((todo) => parseInt(todo.id, 10))
        .sort()
        .at(-1) + 1;
    const todo = { id: `${id}`, title, user: _user };
    self.todos.push(todo);
    // Expected ☝️ this update to propagate to the user referenced in the Todo
    // Instead, 👇 have to update the user's Todos manually
    const user = self.users.find((u) => u.id === _user);
    user.todos.push(id);
  },

This feels like it should be a simple matter of state changes being observed in the usual MobX way, but that doesn't happen here, and I haven't yet made sense of why. Having to update references manually seems counter to what I understand about MobX and MST.

What am I missing from the docs, examples, etc. that addresses how this (seemingly very common) use case would be accomplished with MST? Ultimately, I want to get this right for my project in the simplest, most maintainable way possible.

[coolsoftwaretyler]

Hey @mossymaker - thanks for the detailed question and example.

I think the issue here is unclear documentation. It makes a lot of sense that you would expect the data to be updated automatically baed on the documentation you quoted. I'm sorry for the lack of clarity.

As you found in the earlier discussion, it is actually on you to make sure your data stays normalized. The idea is that we "make it possible" to keep data normalized, but we aren't necessarily going to do it on your behalf.

I'm not one of the original authors, so I can't speak to the actual intention behind that decision, but I think the idea is that we give you the tools to make your own trees work how you want them. My recommendation is:

1. If you only need to keep these references normalized in one place (like how your example just has one action to set the todos), then it makes sense to me to update the references in that spot.
2. If you update the records in multiple actions, or think you might, I would recommend a custom middleware here to keep things correct. You could also consider listening to patches or snapshots and keeping things in order when relevant mutations happen.
3. Additionally, you may find the onInvalidated hook to be useful in keeping things managed behind the scene.

Again, really sorry for the lack of clarity on this. We know the docs need a little extra love, and it's on the list of things to do in 2024. I'd be happy to review any docs clarification PR you want to make. But if that's not interesting to you or you don't have time, I'll just make a note of this discussion as one of the items we need to make sure to improve.

I hope this helps!

[mossymaker]

Thank you for clarifying MST's role in normalization and the suggested approaches, @coolsoftwaretyler. I'm realizing now that I was probably missing the connection between several of the MST concepts.

There's the start of some good explanation material here. I'm interested in contributing to that, but I should figure out how to apply it to my use case first. 😅 I'd like to dig into that original intent, too, so why references behave differently can be made clear.

[coolsoftwaretyler]

Happy to help! If and when you decide to pitch in on docs, I always prioritize reviewing community contributions, so I will be available to help ship it through.

Good luck and have fun!