How to properly memoize children?
I have a small reactivity puzzle that I'm a little stumped on. I'm not sure if I just haven't structured my signals granularly enough, or simply don't understand something, or both.
Essentially I have a pattern like this, in order to implement a list of dynamic inputs (1-N of them):
Where the
.valid
property is being computed and set externally, as a part of updateInput
. There's where the problem comes in - I do want the children of <For>
to update with the signal, and for <ValidTag>
to update, but I do not want the <Input>
to update - it has no need to after initialization, and it re-rendering causes focus to blur (but also is just undesirable).
So, the title suggests one path I could guess out of this (memoizing <Input>
manually), though a naive attempt did not work.
I could guess that splitting the .valid
signal and passing a list of signals, or a store, into <For>
might also work. But mainly, I just want to know what the idiomatic way to do this is - or any way, really. I'm pretty stumped.2 Replies
One other difficulty I mentioned here that might already be obvious from my example, but I'm not exactly sure how to do said splitting of the signals - I've already experimented with that some, and the wall I'm hitting is how to cross the
<For>
boundary - that itself needs to be a signal in order to update the list, otherwise nothing updates. But it seems that as long as it is a signal, everything updates (which does make sense).
I initially tried using a store, thinking that because it would be different signals for each property, it would work as expected, but then I ran into that 'boundary' (because the store object itself was not changing reference)How does the data structure look like and how do you update it
When using a For the data structure can’t be immutable and stored in a single signal.
You have to introduce more points of change, here, for the
. valid
property, and mutate it, instead of the whole inputState object