Make signal react on prop change
Say you initialize a signal by a prop:
If the prop changes, the signal won't react. What must be written is:
Wonder if there's a more idiomatic way in SolidJS though 🤔
12 Replies
sounds like a writable memo:
https://primitives.solidjs.community/package/memo#createwritablememo
Solid Primitives
A library of high-quality primitives that extend SolidJS reactivity
To state the obvious:
The idiomatic way to use a prop is to use the prop directly 😀 .
The idiomatic way to have a derived value from one or more props is to define a function using the props (or use a memo).
Now it's unlikely this answers your questions, however without background of what you want to achieve, it's hard to suggest an idiomatic way to do things.
The problem of your example or the writable memo is that it's kind of a derived value, but not really. If something else writes, it will be something else, until the prop changes. The latest write wins. There are certainly use cases for this, but I would look for alternatives first, as it has the potential for surprising behavior.
There's nothing wrong without updating the state in effect, it's an awkward case though - does the component depend on it's internal state or on props?
@jc_m @.high1 so reading your comments, the case must clarified, as it might be unusual or weird.
I have custom form input components, say a
TextField
(among others). They maintain their own state for errors. For example, I can give it a minLength
attribute and it display an error message if the length inputted by the user is below the requirement.
So I initially had:
All handled in the component itself.
BUT, there are some errors that can't be handled by the component. For example errors that can only be known after a server request. Typical example would be "email already used" in a registration form (I need to hit the db in order to know).
So I allow the TextField
to be given an external error message, through props, so now I have:
But I wonder, maybe this has some complicated effects, where the parent doesn't have an error anymore (empty string), but there was some internal error, and the parent may reset some internal error, not sure. Actually I'm confused now. With tests this works perfectly though as I have written above.The code will work, that's not the issue. The issue here is the component mental model, I would say.
You could also create a derived signal based on both the internal signal value and the prop value.
You have an internal state for which is initialized via props - if that prop updates, the state - signal - will not be updated without the effect. But what's the source of the truth - the prop or the internal state? If the internal stage changed, and then the prop changes - what then? Which one overrides the other?
I always felt like I'm not doing things completely clean when I needed to do this.
thanks for all the input guys, you made it clear that I didn't reason enough about the case and I'll take some time to think about it.
I think it's quite a common thing though, I'm surely not the first to encounter this need
but I need to express my need more clearly, I didnt consider all the cases enough
Derived signal would be fine here I guess, as @._rb proposed.
and yeah, the question at the core is, what is my source of truth. excellent question
In this case, both are active - but separate - so there's no override
Btw ty @._rb my final code is