>> simplest solution is usually the best one to start with. I typically start with redux
?? Redux is definitely not the simplest solution :) I’d argue that starting with local state (which is what hooks seems to be headed towards), then profiling, testing, and adding small amounts of debouncing code where appropriate is more aligned with your sentiment of “don’t prematurely optimize” vs starting with redux.
There's a couple ways to approach building out an app:
- Start as small and as simple as possible, and add more pieces down the road once you need them
- Determine up-front if you think you'll need various pieces, and get that infrastructure in place at the start .
Either of those is a reasonable way to tackle things.
As a related note, I'll put in a pitch for our new Redux Starter Kit 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 without writing any action creators or action types by hand:
Man, why does every single thread about anything remotely related to react devolve into a flamewar about redux? I wish we could all move on from this tired old debate. Everyone is free to use or not to use redux. If your team uses redux and you hate it, that is not redux's fault.
I read the Redux site for the first time recently and I realised that it is a transliteration of the Elm architecture (TEA). TEA is probably easier to understand first as it fits more nicely into its native Elm than Redux does into JS.
I think Redux is quite simple conceptually, but if you just look at the code without the concept and reason behind it, it’ll look like complexity for the sake of it.
More often than not you should have a general feel for how complex your app will grow in the medium / near term. If it's going to get beyond "toy" you might as well take the plunge with Redux up front. Starting your design with it is much easier than trying to shoe-horn it in later, even if the cost at the outset feels heavy.
If you're fairly confident your app won't get too over the top, then by all means go the easy route!
No, it really isn't... but it's a level of complexity that once inherited doesn't get much more complicated as you add more features. It's also imho one of the best options for separating state management.
In general, prop drilling is simpler to start with, but quickly turns into spaghetti... you can use the new context options, but they aren't much easier than using Redux at that point, and can become much more complicated.
You can still slice state into separate reducers and action creators. I use a feature oriented directory structure, so that a given feature may have components/controls, action creators and/or reducers, but not necessarily all of the above.
It sounds a little convoluted, but in practice it's made it easier for developers coming in to discover/predict where things are.
Yep. I've settled on a "feature folder" approach myself. When we finally get around to revamping the Redux docs content, I plan on having a "Style Guide" page similar to the one in the Vue docs, which would offer opinionated suggestions with an indication of how important each one is. One of the items I definitely plan to include in there is a suggestion to use feature folders. I also want to reorganize our example apps based on that structure as well.
I too prefer feature folders. I wish it was the example most used...as it is we have a convention that has no reason other than "this how I first saw it done".
I generally agree but actually the new hooks allow you to pass certain values down to all children automatically, so I think just hoisting this logic to the highest point that makes sense has this covered to some degree.
I think you're talking about context, which isn't specific to hooks. Hooks give functional components features that only existed for classes.
First of all, context is slow, at least currently.
Secondly, it's just a vehicle for delivering deep updates. It should be used when local state is not enough, but it's only an intermediate step before needing redux-like state Management and all the convenience it provides.
There's also a big piece that people who see useContext/useReducer as a replacement for Redux usually miss: server side rendering.
The Redux store lives outside of the React component tree and has a getState() method to capture the state of the store and deliver in the SSR payload. With useContext/useReducer, the state lives in the lifecycle of a top-level component. Unless you build something equivalent to Redux's store anyway, you're not going to be able to easily get a snapshot of its state out of that component. Unless, I suppose, that component itself knows to put its own payload in a <script> tag in its render() on the server only (in which case you'd still get a hydration mismatch).
I would argue that you should indeed hoist your data to the highest point, but definitely not your logic. Otherwise you end up with a big mega-component at the top level that contains fragments of business logic for many unrelated features, and coupling your business logic to your view component hierarchy is not a good idea. Changing your page layout should never break your application. I don't advocate any particular solution to this problem but I do believe that you need some kind of architecture that allows you to decouple your UI code from your application code.
?? Redux is definitely not the simplest solution :) I’d argue that starting with local state (which is what hooks seems to be headed towards), then profiling, testing, and adding small amounts of debouncing code where appropriate is more aligned with your sentiment of “don’t prematurely optimize” vs starting with redux.