FWIW, a lot of people tell us Redux's docs are "great", but we've also had people tell us they aren't helpful. Kinda hard to figure out how to make improvements based on that kind of conflicting feedback :)

We are actually looking at revamping the Redux docs in the near future [0]. If you've got any specific concerns or suggestions on how we can improve things, please let me know directly, or comment on that issue.

Also, besides the docs, you may be interested in my suggested resources for learning Redux [1], including my own Redux workshop slides [2].

[0] https://github.com/reduxjs/redux/issues/2590

[1] http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea...

[2] https://blog.isquaredsoftware.com/2018/06/redux-fundamentals...

For me, it took me a while of working on a web app with derived data everywhere (~15 KB raw JSON that gets updated with diffs and recombobulated into different output formats and different intersections of data with live updates), and endless debugging of data transformations by stepping back and forth through the reducer history, before I really "got" it.

On the note of (b), I really like the redux-actions project (https://redux-actions.js.org) for the way its helpers that get rid of most of that. A simple example:

    const setValueA = createAction('SET_VALUE_A');
    const setValueB = createAction('SET_VALUE_B');
    const setValueAB = createAction('SET_VALUE_AB', (a, b) => ({ a, b }));

    export const reducer = combineReducers({
        valueA: handleActions({
            [setValueA]: (state, action) => action.payload
            [setValueAB]: (state, action) => action.payload.a
        }, null),

        valueB: handleActions({
            [setValueB]: (state, action) => action.payload
            [setValueAB]: (state, action) => action.payload.b
        }, null)
    });

React is best to approach the same way you approach functions: You want to have small components, that do one job, that don't interact with outside state (see below for exception), and are largely ignorant of how your app works. The slight exception is container components, where interacting with outside state should be their sole job, encapsulating the application state interactions and passing the info to the contained components so that they don't have to have that knowledge.

I find a top-down approach works well: Break your page into parts (boxes of content), and then break those down, and so forth. Each box of content will be a component - most will contain others, and the smallest will just have on job.

Move all logic except for simple "show/don't show" into outside functions that you import in to your components - React is the View and you don't want it doing nearly as much as it CAN do. Keep it simple, keep it small.

Remember the key rule: You can pass values DOWN (into contained components) but not UP (into your wrapping components). So if you need to send data "up", you need to pass callbacks down and use those callbacks to pass any data "up". This can feel weird, but it helps keep those contained components ignorant of your larger application, which in turn makes them more reliable overtime, as they aren't impacted by changes outside of themselves.

If you have had limited experience with function best practices, or if you've only worked in deeply OOP systems (that have similar best practices but different concepts for passing data), this can be a bit of a struggle to adjust to, but it's actually a very common pattern, and the reason I use React to teach web dev (after teaching basic vanilla JS) - even after React is obsolete these practices will be useful to follow.

I also recommend learning React BEFORE taking on Redux (or any other application state management lib) - even a simple TODO app (don't copy what is out there, write it without hints, then compare) can help clear up the root concepts, and after that application state management is easier to keep distinct in your mind. I took it all on (React + Flux) at once when I started and it took months to grasp because I wasn't keeping them clear from one another. Redux mapXXXXToProps() functions are in fact quite hard to grasp unless you comfortable with how you use React props in practice, at which point they become straightforward.

And lastly, the switching between class-based components and function-based components can be really confusing. I personally prefer to use almost exclusively function-based components, because React is not expecting you to use an OOP approach to the components. I only use class-based components where I need component state (often only the top-level component for small apps) or if I need to use the lifecycle methods (and I rarely do - many examples use didComponentMount to fire off service calls, but I tend to put those into event handlers, though that gets a lot easier when you are using an application state management lib). but if you prefer class-based components, that's fine - just don't think React is using classes for anything more than providing inheritance of the component methods. No OOP-approach to your components.

Hope this helps!