3 ms·

Why do people like reactivity à la Solid, Vue, MobX etc? The reason I moved away from these towards React was because reactivity introduced subtle bugs with two

Why do people like reactivity à la Solid, Vue, MobX etc? The reason I moved away from these towards React was because reactivity introduced subtle bugs with two way data binding, where it was hard to tell where data was being mutated (v-bind, computed() etc). In contrast, with React I don't really have to worry about that because it explicitly mandates one way data binding with only a few places that data can be changed, such as in click handlers. I can basically treat the state as a render loop that runs from top to bottom every time. If I want to preserve state, I use useState, and if I want to cause an effect, I use useEffect.

fabiospampinato 4y ago
One-way or two-way binding is pretty much completely orthogonal. You can have both approaches in both systems. For instance Solid is pretty close to React in unidirectional flow and read/write segregation. I think the appeal of a reactivity system is different, for some people is better performance, for others it may be better memory usage, for others it may be better DX as a bunch of "workarounds" stop being needed (like dependencies arrays, rules of hooks, useRef, useEvent...), for others it's just simpler to understand and reason about.
- yurishimo 4y ago
  Vue also has a one way data flow, but uses some DX to mask that to something that looks like Angular original two way binding. These days with Vue 3, it’s even more explicitly one way.
- cercatrova 4y ago
  I think of React as a functional language, not exactly, but as a similar mental model. Once you start thinking of React in such a way, a lot of their decisions make sense. Just as in Haskell we need to use somewhat more convoluted ways to make things work, such as monads, we do the same in React, using useEffect to encapsulate side effects (hence the name). We also keep the tree immutable for much the same reason as in functional languages, because immutability tends towards fewer bugs as we don't mutate internal state, but we optimize such immutability through things like a virtual DOM.
threatofrain 4y ago
https://twitter.com/ryancarniato/status/1353801411331416070 https://twitter.com/ryancarniato/status/1353801411331416070 Both React & Solid are consistent here, but I find Solid to be more intuitive.
- rk06 4y ago
  I can see advantage of using React's approach. But why would anyone in right mind want to Not batch dom updates by default?
  - threatofrain 4y ago
    I believe Solid does have batching, and continues to work on the problem?
mmis1000 4y ago
> I can basically treat the state as a render loop that runs from top to bottom every time. If you use vue like this. I think you will never use vue properly. In vue, state IS the ui. UI is always direct mapping of state. You setup state, you describe mapping between state and dom. And the rest of things will be maintained by vue. Data is the trust anchor of everything. UI is derived from it and you shouldn't even think about update it yourself. And vue also makes lots of utils specified to map or handling data change. (Personally I think the most important one is computed, as it is the bridge between the the different form of same state)

fabiospampinato 4y ago

One-way or two-way binding is pretty much completely orthogonal. You can have both approaches in both systems. For instance Solid is pretty close to React in unidirectional flow and read/write segregation. I think the appeal of a reactivity system is different, for some people is better performance, for others it may be better memory usage, for others it may be better DX as a bunch of "workarounds" stop being needed (like dependencies arrays, rules of hooks, useRef, useEvent...), for others it's just simpler to understand and reason about.

yurishimo 4y ago
Vue also has a one way data flow, but uses some DX to mask that to something that looks like Angular original two way binding. These days with Vue 3, it’s even more explicitly one way.
cercatrova 4y ago
I think of React as a functional language, not exactly, but as a similar mental model. Once you start thinking of React in such a way, a lot of their decisions make sense. Just as in Haskell we need to use somewhat more convoluted ways to make things work, such as monads, we do the same in React, using useEffect to encapsulate side effects (hence the name). We also keep the tree immutable for much the same reason as in functional languages, because immutability tends towards fewer bugs as we don't mutate internal state, but we optimize such immutability through things like a virtual DOM.

threatofrain 4y ago

https://twitter.com/ryancarniato/status/1353801411331416070 https://twitter.com/ryancarniato/status/1353801411331416070 Both React & Solid are consistent here, but I find Solid to be more intuitive.

rk06 4y ago
I can see advantage of using React's approach. But why would anyone in right mind want to Not batch dom updates by default?
- threatofrain 4y ago
  I believe Solid does have batching, and continues to work on the problem?

mmis1000 4y ago

> I can basically treat the state as a render loop that runs from top to bottom every time. If you use vue like this. I think you will never use vue properly. In vue, state IS the ui. UI is always direct mapping of state. You setup state, you describe mapping between state and dom. And the rest of things will be maintained by vue. Data is the trust anchor of everything. UI is derived from it and you shouldn't even think about update it yourself. And vue also makes lots of utils specified to map or handling data change. (Personally I think the most important one is computed, as it is the bridge between the the different form of same state)