7 ms·

I’ve been learning React and have been avoiding Redux out of fear of complexity. However, as my app grows more complex, the need for a global state manager beco

• leetrout 7y ago
  Or mobx :)
  • shakopeeant 7y ago
    gross
    • reflectiv 7y ago
      Check out mobx-state-tree ...it's mobx on steroids, and it provides what is missing from mobx to make it a state management solution for large react apps (minus the boilerplate like you get with things like Redux).
• mondaygreens 7y ago
  Try zustand!
  • breytex 7y ago
    https://github.com/react-spring/zustand https://github.com/react-spring/zustand
• brlewis 7y ago
  It's not the amount of complexity that leads to needing Redux, it's the type of complexity. You can go a long way on keeping state in the nearest common ancestor of the components that need to share it. https://redux.js.org/faq/general/#when-should-i-use-redux https://redux.js.org/faq/general/#when-should-i-use-redux
• tempsy 7y ago
  I never understood why redux was considered "hard" - it basically keeps track of a plain javascript object that you can read/write across a react app
  • trufas 7y ago
    I think that plays along the lines of Rich Hickey's simple vs easy idea. Sure, a beginner will understand your explanation, but they might still run into trouble doing common UI things using it. Redux also has a reputation for being annoying to write because people cargo cult it into any project regardless of scope and because utilities like the excellent `redux-toolkit` weren't and still aren't as widespread as they should be.
    • tempsy 7y ago
      any mildly interesting SPA will need to keep track of state somehow. passing state between react components is more complicated than using redux.
    • acemarke 7y ago
      > because utilities like the excellent `redux-toolkit` weren't and still aren't as widespread as they should be. hey, I'm trying to broadcast it as much as I can :) fwiw, the adoption curve is definitely going up: https://npm-stat.com/charts.html?package=%40reduxjs%2Ftoolkit&package=redux-starter-kit&from=2019-01-01&to=2020-02-06 https://npm-stat.com/charts.html?package=%40reduxjs%2Ftoolki... And the growth of the RTK package is especially impressive given that we renamed it from "Redux Starter Kit" to "Redux Toolkit" _after_ we'd released RSK 1.0. We'll emphasize RTK even more as part of the ongoing Redux core docs rewrite. My goal is that it ultimately becomes the default way to write Redux logic, in much the way that the Apollo folks tell you to use `apollo-boost` and React devs default to use Create-React-App.
• dkarl 7y ago
  >I’ve been learning React and have been avoiding Redux out of fear of complexity. Redux seems to be very polarizing about whether it increases or reduces complexity. As a back-end weenie who finds virtually everything about the front end confusing, I found Redux to be a breath of fresh air. Finally something straightforward that made sense and where the complexity of the code never seemed to exceed the complexity of the problem it was solving. But I was working with people who could run rings around me in the big React codebase we were working on who said Redux was a total mindfuck for them and they would never use it again if they had a choice.
• acemarke 7y ago
  Hi, I'm a Redux maintainer. You may be interested in my suggested resources for learning React and Redux: https://blog.isquaredsoftware.com/2017/12/blogged-answers-learn-react/ https://blog.isquaredsoftware.com/2017/12/blogged-answers-le... https://blog.isquaredsoftware.com/2017/12/blogged-answers-learn-redux/ https://blog.isquaredsoftware.com/2017/12/blogged-answers-le... https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links Also, please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. It's our recommended way to write Redux logic: https://redux-toolkit.js.org https://redux-toolkit.js.org Meanwhile, we're working on a major rewrite of the Redux core docs. I'm hoping to put together a new "Quick Start" tutorial page that will show how to use Redux Toolkit and React-Redux in a "top-down" approach as a fast way to get productive. The current tutorials take a "bottom-up" approach, teaching how Redux works from first principles. I also want to rewrite those, keeping the same teaching flow, but updating the content to be easier to understand and to teach patterns that result in simpler code.
• karatestomp 7y ago
  1) Redux is pretty simple, but some of the terminology is obtuse for no good reason and makes it harder to get a grip on than it should be. "Action" = event, "Action Creator" = any function that emits an event, it's basically... not even a real thing worth discussing with its own special term. There, problem mostly solved. 2) TypeScript is the only sane way to use it. The bouncing between files and "wait, what was the shape of my state here?" crap is intolerable without it. I mean that's broadly true of all Javascript but it's very noticeable with Redux. This is doubly true if you're working on a team. 3) I've had a lot of luck abstracting Redux behind a broader client library of some sort. You can expose the redux store itself and let the using code "compose" it as usual, but stick most of the "action creator" stuff behind the wall of the library, minimizing and moving to a more suitable level of abstraction the surface area the calling code is exposed to. This is especially nice if you may use the code in some environments where you don't want to or can't practically use React—you can still easily re-use the Redux portions, which is wonderful. Also tends to leave you with state code that's easier to test in isolation. 4) One of the big limitations of it is that you can't reference one part of your state from another. You have to copy, because of how Redux automagically detects changes to the state tree. This has been a lot more annoying and limiting than I thought it would be at first—turns out I need/want to do that more often than I thought I did, and the more complex the app the more I want to do it—but you've either got to learn to live with it or have some kind of external, supplemental state management alongside Redux.
  • acemarke 7y ago
    Understanding the original context and intent of a tool is important. Back in 2017, I wrote a post that covered the overall intent behind Redux's design [0], as I was already seeing that folks didn't know the background. That lack of understanding behind Redux's history has become more apparent over time. The terminology exists because Redux was originally designed as "just" another implementation of the Flux Architecture. Both "actions" and "action creators" were terms that had already been introduced by Flux [1]. There was considerable debate during the initial design phase about what terms to use, and the conclusion was to stick with Flux terminology to match the target audience of the time [2]. Note that the new Redux Style Guide docs page specifically recommends "modeling actions as 'events'" [3], using the "ducks" pattern for single-file Redux logic [4], and writing Redux logic using TypeScript [5]. In addition, our new official Redux Toolkit package [6] is our recommended approach for writing Redux logic. It has several utilities for common use cases like setting up the store, writing immutable updates, and creating slices of state, and it's written in TypeScript with an API designed to minimize the amount of type declarations you have to write. (In fact, I've even used its `createSlice()` function to write some fairly complex reducer logic that I used with React's `useReducer` hook.) Finally, you _can_ reference multiple parts of the state tree in your reducer logic, but you have to explicitly set that up yourself [7]. The `combineReducers` utility is meant for the standard use case of defining update logic by domain "slices", and it's up to you to write custom logic if you need more specific behavior than that. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/#the-intent-and-design-of-redux https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://facebook.github.io/flux/docs/in-depth-overview#actions https://facebook.github.io/flux/docs/in-depth-overview#actio... [2] https://github.com/reduxjs/redux/issues/891#issuecomment-147666329 https://github.com/reduxjs/redux/issues/891#issuecomment-147... [3] https://redux.js.org/style-guide/style-guide#model-actions-as-events-not-setters https://redux.js.org/style-guide/style-guide#model-actions-a... [4] https://redux.js.org/style-guide/style-guide#structure-files-as-feature-folders-or-ducks https://redux.js.org/style-guide/style-guide#structure-files... [5] https://redux.js.org/style-guide/style-guide#use-static-typing https://redux.js.org/style-guide/style-guide#use-static-typi... [6] https://redux-toolkit.js.org https://redux-toolkit.js.org [7] https://redux.js.org/recipes/structuring-reducers/beyond-combinereducers https://redux.js.org/recipes/structuring-reducers/beyond-com...
• protonimitate 7y ago
  Personally I would recommend using React's bult in Contexts before jumping straight to redux. Redux is great when needed, but can easily over-complicate something that can easily be solved by Context.
• nohuhu 7y ago
  Check out Statium: https://github.com/riptano/statium https://github.com/riptano/statium, and the RealWorld example that I threw together in a couple of evenings: https://github.com/nohuhu/react-statium-realworld-example-app https://github.com/nohuhu/react-statium-realworld-example-ap.... The basic idea is to have state kept in a separate component that deals just with state, a ViewModel. Internally it works just the same as usual React components: by calling `this.setState()`; externally it exposes API for getting key values and setter functions, same as hooks do. It's really easy to work with, and the concept of hierarchical state store is something that I haven't seen in any other library. If there was I probably wouldn't end up writing Statium in the first place. :)
• veeralpatel979 7y ago
  Hey - author here. Try Redux; acemarke has been evangelizing Redux Toolkit [1] recently and it looks great for a beginner not familiar to the Redux ecosystem. But also - if Redux just isn't clicking for you, or if it is but you feel like writing it is unnatural - know that you're not alone. Learn MobX, learn how to manage state with context and hooks [2], learn Apollo Client. Yes it's a lot of up-front work, but you really do need to find a state management approach that works for you if you want to write non-trivial apps, in my opinion. [1] https://redux-toolkit.js.org/ https://redux-toolkit.js.org/ [2] https://kentcdodds.com/blog/application-state-management-with-react https://kentcdodds.com/blog/application-state-management-wit...