Granular DOM updates when array is modified

[quixot1c]

Does Solid only update the affected DOM nodes when for example an array of strings is rendered into a table and somewhere from the middle of the array a string is removed? Is this handled differently between Signals and State? I would assume it is, because Signals seem to be truly immutable and produce a completely new value each time, which would need to be diffed in order to know which DOM nodes to update. While State makes it possible to only change part of the model, which to the outside user seems to result in a completely new object, but is in effect tracking all changes through its Proxy. Am I correct in this?

[ryansolid]

They aren't handled differently. It's one of the reasons to use state vs signals. There is only shallow diffing anywhere in the DOM handling side of things. For simple changes on nodes we are talking primitive values, strings numbers etc.. So there isn't really much concern here on updates here. But for nested values it gets trickier. If you use a signal to hold an array of objects and only want to update one property on it, well you are going to do wasted work. You are going to blow out the whole row. State is better here.

If you are talking about an array of strings though, it doesn't really matter which way you go. And in the term of list handling you probably want to use <Index> to key by index instead of <For> since any editing of the strings will no blow out the row. I've debated adding a <Key> helper for specific keys but that scales worse as a pattern for nested data.

[quixot1c]

Well my use case is that I am getting quite a large array of tuples [string, string][] (large in length, but only two columns) from some server and there is a websocket connection that receives updates to these tuples. These updates come in multiple times a second and I don't want to redraw the whole list on each update. Should I use <Index> there? The docs say it's not recommended to do so?

I don't really get what you mean when you say they aren't handled differently but that is one of the reasons to use Signals. If they are the same why choose one over the other? :) Both only report changes to the reactivity system regarding their complete state and not individual properties being updated? Do you have a diagram or some more in depth resource on how rendering updates? Or is the example of the compiled template all I should need and should I just look at it a little harder? :P

[ryansolid]

With attributes it's easy to look at the output but array handling uses helpers that are a bit more involved. I meant if you want nested updates that's one of the reasons to use State, it saves you from wrapping everything in Signals yourself to keep things granular. The renderer doesn't treat them specially. If Signals aren't granular you end up re-evaluating everything. Some places in the view might diff old values but any sort of child insert reconciliation code needs to run again and may lead to more downstream changes if it can't determin they are the same.

As for your data structure do you ever swap rows? Is there conceptually a key, a unique identifier per row? I suspect you want <Index> here. I probably should clarify in that writeup. I guess with Solid people wouldn't opt into Index just being lazy like they do in other frameworks it's fine to not put such a big disclaimer. Generally speaking keyed is better than non-keyed for any non-primitive data structure. But if there is no key then it's fine.