3 ms·

FTA: "It means going from: Frontend > React > [state management library of choice] to Frontend > Data Layer > View Layer (React) " I'm not really

FTA: "It means going from: Frontend > React > [state management library of choice] to Frontend > Data Layer > View Layer (React) " I'm not really sure what "Frontend" means here, but I'm pretty sure this is how I was using React + Redux, back when I was developing in that ecosystem a ton. I certainly wouldn't diagram it as the first example. The hard part with doing this "purely" is that it'll murder performance for text inputs and animations. All this developer-centered convenience comes at a performance & resource-use cost to the user, it's just most-obvious when you're dealing with forms and animations.

zdragnar 5y ago
Having also been in that area, I almost never put forms or animation state into the redux store. Sure, you lose a certain amount of time-travel goodness, but it made for a much saner development experience (especially where performance was concerned).
- moshmosh 5y ago
  Yeah, you basically can't do that without wrecking performance, which is why I think attempts at more "functional purity" (which, LOL, React has now entirely abandoned anyway, see: hooks) and "single-source-of-truth" than what's currently the norm in the React world (or anywhere else in FE web dev) are misguided.
  - zdragnar 5y ago
    I still prefer a global store and keeping functions as pure as possible. I just make a distinction between application state and ephemeral (i.e. local state such as drag / drop tracking, forms, etc). There are a number of advantages to centralizing your event handling pipeline and using middleware functions to perform many of the more important side effect producing behaviors (i.e. analytics events, etc.). YMMV though, and I now that I am working on an app that makes extensive use of hooks and useContext, I cant say that the world has ended (even if it is quite a bit more confusing).
- acemarke 5y ago
  Yes, we specifically recommend that most "form state" should _not_ go directly into Redux: - https://redux.js.org/style-guide/style-guide#avoid-putting-form-state-in-redux https://redux.js.org/style-guide/style-guide#avoid-putting-f... - https://redux.js.org/faq/organizing-state#should-i-put-form-state-or-other-ui-state-in-my-store https://redux.js.org/faq/organizing-state#should-i-put-form-... In other words: it's fine to take data that's in the Redux store, use that to initialize a React form, do the form updates in local state, and then dispatch an action containing the final results when the form is complete. But, there's almost never a good reason to dispatch a Redux action on every keystroke. You don't need to track that level of granularity in the Redux DevTools, other components in the app are unlikely to need to see those individual updates, and it's a waste of update and subscription handling.
  - Joker_vD 5y ago
    By the way, about that "dispatch an action containing the final results when the form is complete" — what is the Correct Way™ to do this, if there may be several instances of the form? They should produce different actions so that different pieces of state would be updated.
    - acemarke 5y ago
      "It Depends"? :) Typically if you've got a single React component type that is supposed to be reused in multiple places with differing behavior, the right answer is "pass in something as a prop". In this case, that could be a callback function that dispatches the correct action, so the form component can just do `props.onFormCompleted(data)`, and the differing usage sites can pass in different callbacks that dispatch different actions.
  - arenaninja 5y ago
    If only my PMs had cared... I previously worked on a monstrosity where the input state was owned by the backend via huge incomprehensible metadata updates. Every keystroke had to be submitted (and thus actions fired) because a field update could invalidate other fields on the grid and the user could feel the latency (~400ms roundtrip?) between each keystroke. The backend team was sure they had discovered some magic sauce and I noped out of there before my next bonus

zdragnar 5y ago

Having also been in that area, I almost never put forms or animation state into the redux store. Sure, you lose a certain amount of time-travel goodness, but it made for a much saner development experience (especially where performance was concerned).

moshmosh 5y ago
Yeah, you basically can't do that without wrecking performance, which is why I think attempts at more "functional purity" (which, LOL, React has now entirely abandoned anyway, see: hooks) and "single-source-of-truth" than what's currently the norm in the React world (or anywhere else in FE web dev) are misguided.
- zdragnar 5y ago
  I still prefer a global store and keeping functions as pure as possible. I just make a distinction between application state and ephemeral (i.e. local state such as drag / drop tracking, forms, etc). There are a number of advantages to centralizing your event handling pipeline and using middleware functions to perform many of the more important side effect producing behaviors (i.e. analytics events, etc.). YMMV though, and I now that I am working on an app that makes extensive use of hooks and useContext, I cant say that the world has ended (even if it is quite a bit more confusing).
acemarke 5y ago
Yes, we specifically recommend that most "form state" should _not_ go directly into Redux: - https://redux.js.org/style-guide/style-guide#avoid-putting-form-state-in-redux https://redux.js.org/style-guide/style-guide#avoid-putting-f... - https://redux.js.org/faq/organizing-state#should-i-put-form-state-or-other-ui-state-in-my-store https://redux.js.org/faq/organizing-state#should-i-put-form-... In other words: it's fine to take data that's in the Redux store, use that to initialize a React form, do the form updates in local state, and then dispatch an action containing the final results when the form is complete. But, there's almost never a good reason to dispatch a Redux action on every keystroke. You don't need to track that level of granularity in the Redux DevTools, other components in the app are unlikely to need to see those individual updates, and it's a waste of update and subscription handling.
- Joker_vD 5y ago
  By the way, about that "dispatch an action containing the final results when the form is complete" — what is the Correct Way™ to do this, if there may be several instances of the form? They should produce different actions so that different pieces of state would be updated.
  - acemarke 5y ago
    "It Depends"? :) Typically if you've got a single React component type that is supposed to be reused in multiple places with differing behavior, the right answer is "pass in something as a prop". In this case, that could be a callback function that dispatches the correct action, so the form component can just do `props.onFormCompleted(data)`, and the differing usage sites can pass in different callbacks that dispatch different actions.
- arenaninja 5y ago
  If only my PMs had cared... I previously worked on a monstrosity where the input state was owned by the backend via huge incomprehensible metadata updates. Every keystroke had to be submitted (and thus actions fired) because a field update could invalidate other fields on the grid and the user could feel the latency (~400ms roundtrip?) between each keystroke. The backend team was sure they had discovered some magic sauce and I noped out of there before my next bonus