3 ms·

I've written a fair few Solid apps. I've never felt the need to reach for 3rd party tools to help manage state. In my experience, solid's built-in signals (& re

I've written a fair few Solid apps. I've never felt the need to reach for 3rd party tools to help manage state. In my experience, solid's built-in signals (& resources) are enough on their own for simple apps. And when I need something more complex, you can build on top of them if you know what you're doing. If anyone is curious, here's an interactive, editable tutorial teaching how solidjs signals work. If you haven't seen solid before, its similar to react but components don't re-run whenever their state changes: https://www.solidjs.com/tutorial/introduction_signals?solved https://www.solidjs.com/tutorial/introduction_signals?solved Am I missing out on some whiz bang magic that the react ecosystem has invented? Is it substantially better than what solid provides out of the box?

koakuma-chan 1y ago
I agree that Solid signals and resources are robust, but they are still very similar to React's useState and useEffect, and you are basically suggesting to implement your own state management library. Regardless, with React server components, there is no need to manage state on the client at all.
- josephg 1y ago
  Ah the classic retort. X is merely a broken version of Y. Y has flaws. Therefore X has all of flaws of Y. No. I don’t accept that. Certainly not prima facie. Solid isn’t a broken version of react. It’s a fixed version of react. Signals aren’t the same as useState because in solid, dependencies are tracked automatically when you read from them and components automatically rerender as a result. Also because component functions are only executed once, it’s usually pretty easy to just add any state management you want into the body of a component. At least that’s been my experience with solid so far. I’d love to see a counter example in which these external state management libraries actually add value?
  - koakuma-chan 1y ago
    I am not interested in arguing whether state management libraries add value, or how React useState compares to Solid createSignal, but I will reiterate that with React server components, there is no need to manage state on the client at all.
    - owebmaster 1y ago
      Yeah because then you are managing a session in the backend. A backend that is not necessary. But still billing.

koakuma-chan 1y ago

I agree that Solid signals and resources are robust, but they are still very similar to React's useState and useEffect, and you are basically suggesting to implement your own state management library. Regardless, with React server components, there is no need to manage state on the client at all.

josephg 1y ago
Ah the classic retort. X is merely a broken version of Y. Y has flaws. Therefore X has all of flaws of Y. No. I don’t accept that. Certainly not prima facie. Solid isn’t a broken version of react. It’s a fixed version of react. Signals aren’t the same as useState because in solid, dependencies are tracked automatically when you read from them and components automatically rerender as a result. Also because component functions are only executed once, it’s usually pretty easy to just add any state management you want into the body of a component. At least that’s been my experience with solid so far. I’d love to see a counter example in which these external state management libraries actually add value?
- koakuma-chan 1y ago
  I am not interested in arguing whether state management libraries add value, or how React useState compares to Solid createSignal, but I will reiterate that with React server components, there is no need to manage state on the client at all.
  - owebmaster 1y ago
    Yeah because then you are managing a session in the backend. A backend that is not necessary. But still billing.