Most people take umbridge because Redux was cargo culted in the first place, cargo culting against it isn't that helpful. I think the website shared in this post is a great approach. Show everyone the options and let them decide what solution fits their problem.
Also, two-way-data-bindings like just `state.totals` work when you're just re-rendering your whole app on every frame, but as soon as you get away from that, there will always be either some "observing" or "signalling" involved to trigger rerendering of the correct parts of your application. Redux goes the "signalling" way, MobX goes the "observing" way, both have their benefits and drawbacks.
--- start quote ---
import { combineReducers } from 'redux'
import { createStore, applyMiddleware } from 'redux'
import thunkMiddleware from 'redux-thunk'
const composedEnhancer = composeWithDevTools(applyMiddleware(thunkMiddleware))
import { createSlice } from '@reduxjs/toolkit'
...createSlice will automatically generate action creators
--- end quote ---
It's.... it's not better in any way?
> Redux goes the "signalling" way, MobX goes the "observing" way, both have their benefits and drawbacks.
I like Svelte's approach. Where they figure out which things are being observed or changed at compilation/transpilation time and generate code for that case specifically.
In the end you are left with only
`import { configureStore, createSlice } from '@reduxjs/toolkit'`
Perhaps. As person who's never used thunks or, really, half of those tools in conjunction with Redux, this tutorial is quite confusing.
> In the end you are left with only import { configureStore, createSlice } from '@reduxjs/toolkit'
The final code on the page is literally
import {
createSlice,
createSelector,
createAsyncThunk,
createEntityAdapter
} from '@reduxjs/toolkit'
- You've gone through this whole tutorial sequence and should now understand how to write all this Redux logic "by hand" and why these standard Redux usage patterns exist
- Now, here's how Redux Toolkit abstracts and simplifies those exact same patterns, so that you can do the same thing with less code, but you understand what those abstractions are doing for you internally.
There's no need to rerender the whole frame - will be happy to provide an example on request.
The upside of an action-based (signalling) approach is that you have a better time separating concerns as actions (if used correctly) represent intent, so your component emits an event and the state acts accordingly, removing state logic from your representational components. Might also be a lot easier to see in the DevTools what happened when and why.
Of course not every app needs a pattern like that, that's why I said both approaches are valid.
Regarding DevTools, it's just as easy to make it work with "observing".
Also, I'm not saying you should write state changes and data fetching in the UI components. By all means write them under actions/services whatever. I'm complaining about the complexity around effecting that change.
It's not much more code than writing a function, but other reducers of your state can suddenly act upon the same action, you can trigger side effects using middleware and of course watch stuff "by intent" and not "there was a modification" in the devtools. All while keeping everything separated pretty well.
Also, with action factory, step 1 can be automated.
https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
It doesn't eliminate the "dispatch actions" concept, because that's core to how Redux works. But, it does simplify the vast majority of your Redux logic considerably.
It's a nice pattern but in an artistic sense.
Changing UI state 10 years back:
state.totals = 100;
Changing state today:
1. Call an action creator
2. Dispatch an action to the reducer
3. Switch by action type
4. Apply action on state
5. Return new state
So imho the problems start right at the bottom - the extreme verbosity and the redundancy.