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.

[amb26]

Thanks, this discussion is extremely helpful and could well be promoted to being an official part of the docs. I'm happy to see the signals approach (and especially together with preact's rendering optimisations) gaining ground over opaque approaches such as hooks, but based on this discussion something doesn't seem quite right to me. What should be a UI-level decision appears to have affected our structuring of the underlying data, and even the paths we use to address it - whether we consume todo.done or todo.done.value is a "breaking change".

I'm aware that we are close to the limits of what can be done here ergonomically, and I'm wondering whether this is the kind of issue referred to such article https://dev.to/this-is-learning/the-evolution-of-signals-in-javascript-8ob speculating that "JavaScript might not be the best language for signals". One possible route here is the use of Proxies but these have their own performance and usability issues. Could anyone comment here on how they feel a language could do better at transparently accommodating reactivity, without forcing people to prematurely bake update granularity decisions into the data model? Or experience of other languages that do this.

[marvinhagemeister]

I feel like whenever people pull out the "we need a specialised programming language for this"-card they usually underestimate the complexity that comes with it and the mental overhead that would add for developers. If you go to JS developers and say "hey, to use signals you need to learn a new language" then I struggle to see how this would gain traction outside of theoretical realms. Bringing signals to an existing language certainly has its tradeoffs, but to me the outweigh the benefits of not having to bring another language into your stack.

If you prefer a more Proxy-based API to signals, there is deepSignal which is written by the fine folks over at WordPress. From an implementers perspective not going the Proxy route is much simpler, but I'm coming around to the Proxy approach given that it is easier for folks to pick up, especially when it comes to collections.

(...)but based on this discussion something doesn't seem quite right to me. What should be a UI-level decision appears to have affected our structuring of the underlying data, and even the paths we use to address it - whether we consume todo.done or todo.done.value is a "breaking change".

Do you feel splitting data + UI would make much of a difference for a todo app? I certainly get your point that some apps need that sort of separation. With my explanation from last year I wanted to point out that there are different ways to think about state and that the granularity of reactivity that is needed depends on the requirement of the specific project in question.

Maybe you can share a better example that you feel like is more fitting?