logoalt Hacker News

iainmerricktoday at 4:37 PM1 replyview on HN

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.


Replies

ryansolidtoday at 6:51 PM

Thank 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-signal...