5 ms·

Good rule of thumb is to disregard any statement like "Literally never ever ... under any circumstances" irregardless of the supposed reputability of the person

Good rule of thumb is to disregard any statement like "Literally never ever ... under any circumstances" irregardless of the supposed reputability of the person saying it. Its either purposely meant to be a hot take to rile people up or its lacking nuance. As other comments have mentioned, he has valid concerns and some opinions about what a preferable architecture looks like but for whatever reason he chose not to lead with that.

jeswin 6y ago
Redux became a thing because of Dan Abromov's impressive tutoring and documenting skills early on and due to acemarke being a good leader after he left. 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.
- phryneas 6y ago
  That does not sound like you are up-to-date with what the official redux tutorials currently recommend for writing modern redux. https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... 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.
  - jeswin 6y ago
    What's one good reason why JS proxies (which let you listen to "state.totals = 100") aren't a cleaner solution to trigger a rerender? There's no need to rerender the whole frame - will be happy to provide an example on request.
    - phryneas 6y ago
      That would be the "observing" approach I described. 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.
      - jeswin 6y ago
        My point is that the action-based approach you describe is extremely verbose for very little gain. Most apps don't need it, yet that's what Redux forces you to do. 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.
        phryneas 6y ago
        It doesn't seem verbose to me. Have you looked into those docs above? You define a reducer and an action creator is automatically generated. String action types are an implementation detail. No manual immutable state modification, as immer is baked in. Modern redux is maybe 20% of what you might be imagining if you only know legacy redux. 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.
  - dmitriid 6y ago
    > That does not sound like you are up-to-date with what the official redux tutorials currently recommend for writing modern redux. https://redux.js.org/tutorials/fundamentals/part-8-modern-re https://redux.js.org/tutorials/fundamentals/part-8-modern-re... --- 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.
    - phryneas 6y ago
      That page introduces one tool after another, replacing all those external tools with the officially recommended Redux Toolkit that wires all of them up for you. In the end you are left with only `import { configureStore, createSlice } from '@reduxjs/toolkit'`
      - dmitriid 6y ago
        > That page introduces one tool after another, replacing all those external tools with the officially recommended Redux 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' The page doesn't really address the issue of verbosity and the flow as described in the original comment. It just hides some of it behind some facades with autogenerated accessor functions (so, even more levels of abstractions).
        acemarke 6y ago
        Yes, the entire point of that page is: - 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.
- richeyryan 6y ago
  I'm not saying anything about the actual tools here. I have an opinion of course but that's not relevant here. What I'm saying is most technical decisions require nuance and thought. If someone is presenting a thought without any room for nuance, it probably doesn't stand up to scrutiny. What the frontend community needs is more honest and nuanced appraisals of tech and less cargo culting. 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.
- IceHegel 6y ago
  More steps can be good if they clarify thinking (Typescript) and make code more intuitive. Complex apps have complex state and Redux handles that really well. It might no be needed for a TODO list tutorial, but comments like these are what prevented me learning Redux (I was like wtf are dispatch, action, thunk - seems lame) when it's actually a great tool that often reduces complexity. Also, with action factory, step 1 can be automated.
  - acemarke 6y ago
    Note that our official Redux Toolkit package is the recommended approach for writing Redux logic: https://redux-toolkit.js.org https://redux-toolkit.js.org https://redux.js.org/tutorials/fundamentals/part-8-modern-redux 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.

jeswin 6y ago

Redux became a thing because of Dan Abromov's impressive tutoring and documenting skills early on and due to acemarke being a good leader after he left. 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.

phryneas 6y ago
That does not sound like you are up-to-date with what the official redux tutorials currently recommend for writing modern redux. https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... 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.
- jeswin 6y ago
  What's one good reason why JS proxies (which let you listen to "state.totals = 100") aren't a cleaner solution to trigger a rerender? There's no need to rerender the whole frame - will be happy to provide an example on request.
  - phryneas 6y ago
    That would be the "observing" approach I described. 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.
    - jeswin 6y ago
      My point is that the action-based approach you describe is extremely verbose for very little gain. Most apps don't need it, yet that's what Redux forces you to do. 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.
      - phryneas 6y ago
        It doesn't seem verbose to me. Have you looked into those docs above? You define a reducer and an action creator is automatically generated. String action types are an implementation detail. No manual immutable state modification, as immer is baked in. Modern redux is maybe 20% of what you might be imagining if you only know legacy redux. 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.
- dmitriid 6y ago
  > That does not sound like you are up-to-date with what the official redux tutorials currently recommend for writing modern redux. https://redux.js.org/tutorials/fundamentals/part-8-modern-re https://redux.js.org/tutorials/fundamentals/part-8-modern-re... --- 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.
  - phryneas 6y ago
    That page introduces one tool after another, replacing all those external tools with the officially recommended Redux Toolkit that wires all of them up for you. In the end you are left with only `import { configureStore, createSlice } from '@reduxjs/toolkit'`
    - dmitriid 6y ago
      > That page introduces one tool after another, replacing all those external tools with the officially recommended Redux 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' The page doesn't really address the issue of verbosity and the flow as described in the original comment. It just hides some of it behind some facades with autogenerated accessor functions (so, even more levels of abstractions).
      - acemarke 6y ago
        Yes, the entire point of that page is: - 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.
richeyryan 6y ago
I'm not saying anything about the actual tools here. I have an opinion of course but that's not relevant here. What I'm saying is most technical decisions require nuance and thought. If someone is presenting a thought without any room for nuance, it probably doesn't stand up to scrutiny. What the frontend community needs is more honest and nuanced appraisals of tech and less cargo culting. 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.
IceHegel 6y ago
More steps can be good if they clarify thinking (Typescript) and make code more intuitive. Complex apps have complex state and Redux handles that really well. It might no be needed for a TODO list tutorial, but comments like these are what prevented me learning Redux (I was like wtf are dispatch, action, thunk - seems lame) when it's actually a great tool that often reduces complexity. Also, with action factory, step 1 can be automated.
- acemarke 6y ago
  Note that our official Redux Toolkit package is the recommended approach for writing Redux logic: https://redux-toolkit.js.org https://redux-toolkit.js.org https://redux.js.org/tutorials/fundamentals/part-8-modern-redux 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.