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.