3 ms·
That's not quite right! I made the same mistake in a Solid project. The deal is that your `props` parameter is reactive. If you use `props.x`, and the value of
by iainmerrick 1y ago
That's not quite right! I made the same mistake in a Solid project.
The deal is that your `props` parameter is reactive. If you use `props.x`, and the value of `x` later changes, that bit of your component will update.
The catch is that you have to access it via `props` -- if you extract it, e.g. "const { x } = props", subsequent uses of `x` aren't reactive. Sometimes that's actually what you want, sometimes not.
Like you, I ended up turning lots of props into accessor functions -- `props.x()` -- so it's clear exactly when they're being used. This isn't necessary if you're careful to access via `props` and not extract fields prematurely. But sometimes I like being explicit about it, so I still sometimes use function props.
- ryansolid 1y agoThank you for correcting this. I was going to come and respond when I saw this earlier but hadn't had a chance. Yes the annoying part is not being able to destructure but you definitely don't have to (and it isn't our recommendation) to pass accessor functions down as props. I wrote an article on our perspective here: https://dev.to/this-is-learning/thinking-locally-with-signals-3b7h https://dev.to/this-is-learning/thinking-locally-with-signal...