Any recommendations on how to structure complex data?

[astoilkov]

I'm trying to wrap my head around using signals for our app. Should I use nested signals for complex data?

For example, the todos example. What if I don't want to update all todos when a single todo changes? Should I do the following?

const todos = signal([
  signal({ text, done }),
  signal({ text, done })
])

[marvinhagemeister]

Depends on how granular you want to react to changes to todo items. There is no right or wrong approach here. With signals I notice that my own thinking shifted from "when/how do I update things" to "when do I need to sync with the UI".

In your example you wrapped each todo item with a signal:

const todos = signal([
  signal({ text, done }),
  signal({ text, done })
])

That works too, and there is nothing wrong with that approach. Only minor annoyance with that is, that whenever you update a todo's .done property, the code that renders the text always needs to be updated too. What's more is that you likely mapped over the list and rendered the items in the same component, which would subscribe the component to both the todos signal, as well as to every signal inside that array.

<ul>
  {todos.value.map(todo => {
    const { text, done } = todo.value;
    return <li>{text}, completed: {done ? "yes" : "no"}</li>
  })}
</ul>

In essence the whole component would re-render everytime we update any of the signals, because all of them are accessed inside the render function. So there isn't really anything we gain by wrapping each item into a signal here.

Back to your original question: How granular reactive should my state be?

Determine granularity

Let's continue with the todo list example:

The raw example in our docs looks somewhat like this, were only the whole thing is one big signal. We did that because we didn't want to overload folks new to signals with everything at once. For such a simple app like a todo app, this is perfectly fine too.

const todos = signal([
  { text },
  { text }
])

The reason this is perfectly fine is that once you push a new item into the array, you want all code that depend on the array to re-render anyway. The text of each item isn't editable after a todo item was added, so there is no point in making more stuff reactive.

But let's imagine we would add a .done status boolean like in your example. With that our UI has a checkbox next to each todo item where they can check and uncheck todo items. We could totally do that with the current way of managing everything in a big signal, but in this case opting for more granular reactivity makes it a little nicer and potentially faster.

const todos = signal([
  { text, done: signal(false) },
  { text, done: signal(true) }
])

In our UI we can then bind the checkbox directly to this signal and bypass components that depend on the whole todo items array (=the outer signal).

Let's imagine we want to add a little blurb under the list of todo items which says something like

Congratulations, you completed X todos

For that we could add a computed() signal to map over the list of todos.

const todos = signal([
  { text, done: signal(false) },
  { text, done: signal(true) }
])

const completed = computed(() => {
  return todos.value.filter(todo => todo.done.value).length;
});

Because the .done property of each todo item is reactive, we benefit from that here, because our computed updates whenever new items are pushed to the todo array and when a todo's .done value changes. We could use the returning completed signal and pass it directly into JSX as text again.

<p>Congratulations, you completed {completed} todos</p>

Summary

In summary, it's always a question of "when do I need to sync with the UI" and how granular you want to react to state updates.

[astoilkov]

Got it. This was very well explained.

I'll continue exploring signals for a possible library we could use for https://nota.md/. Are the issues a good place to start discussions and ask for more detailed / architecture-level questions?

[marvinhagemeister]

@astoilkov sure, feel free to post any further questions here. I quite enjoy these kind of discussion and issues here are perfect for that.