[satvikpendem]

Personally I just use Redux Toolkit with RTK Query for any synchronization with backend state. What I like about Redux is that it takes the immutable functional approach, you cannot change previous state but must instead derive new state from the old state very explicitly. In this way, it's the antithesis of signal-based state.

[dmitriid]

> What I like about Redux is that it takes the immutable functional approach

Strange that you don't like spaghetti, but then praise Redux that is spaghetti exemplified: dozens of functions, and wrappers, and hooks eerywhere. Trying to trace how a value gets changed through the three-four layers of wrappers is like pulling teeth through the anus.

And looking at the current reincarnation of this abomination, it is marginally less spaghetti, and converging on the same signals code that everyone is converging on.

[satvikpendem]

Redux Toolkit is very impressive, especially with TypeScript. I'd agree that there was a lot of boilerplate in the before-times, but today, it's not "marginally less," it's significantly less boilerplate. The debugging tools are top notch as well, I can trace values and their changes pretty easily these days.

The main point of Redux is that it follows functional programming paradigms of immutable data, which makes reasoning about changes much easier. Compare that to the global state everywhere of signals/reactive/observables-based approaches like MobX or RxJS.

[dmitriid]

> Compare that to the global state everywhere of signals/reactive/observables-based approaches like MobX or RxJS.

What are you on about? Redux is literally about global state everywhere. But with three to four layers of abstractions between.

You define your state globally. Then use hooks to fetch data from that global state, and then "dispatch" aka call actions on that global state. If something else somewhere else updates data in that global state your component will be affected if it uses that data.

But it also requires you to write an insane amount of useless stuff like "define your store, then reducers, then slices, then god knows what" to arrive at almost the same code:

   // redux

   import { useSelector, useDispatch } from 'react-redux'
   import { decrement, increment } from './counterSlice'

   export function Counter() {
     // note how we reach into magical global state that useSelector knows about
     const count = useSelector((state: RootState) => state.counter.value)
     const dispatch = useDispatch()

     return <>
        <button onClick={() => dispatch(increment())}>Increment</button>
        <span>{count}</span>
        <button onClick={() => dispatch(decrement())}>Decrement</button>
     </>;
   }


   // solid

   // state is immutable. It's also not magical, you explicitly refrence and import it
   //
   // increment and decrement would use a `set` function to update the store to required value
   // see https://www.solidjs.com/docs/latest/api#createstore
   // and https://www.solidjs.com/docs/latest/api#updating-stores
   //
   import { state, increment, decrement } from './counter-store';

   export function Counter() {
     return <>
        <button onClick={() => increment()}>Increment</button>
        <span>{state.count}</span>
        <button onClick={() => decrement()}>Decrement</button>
     </>;
   }

[satvikpendem]

Solid is basically using the same Flux architecture that Redux and Vuex is using then, with stores and actions. It's just more hidden away than in Redux which is more explicit. Yes, I do want to explicitly see what my data store looks like and in Redux I'm able to. That I have to create slices (which are automatically mapped to TypeScript by the way) is fine with me, it's only a few lines more than in your Solid example.

To add, this is also why I explicitly mentioned Rx and Mob, which are not as clean as the Flux architecture in terms of creating spaghetti code. And I believe we are also defining spaghetti differently. Spaghetti != boilerplate.