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].
Maybe I can help on this one. I'm midway through learning Redux - enough to have stuff working, but not enough to write complex UI code with it.
The problem for me is that Redux uses a set of higher order constructs, which requires a set of functional abstractions that are pretty unique to Redux and Redux-likes. There isn't remotely enough documentation to explain why the boilerplate is put where it is or named the way it is, so I have working code, but no real understanding of why the boilerplate is this way vs. any other way.
So what happens in the docs is that I follow the tutorial along, and it's great about setting up the problems to show why Redux is useful, but then it goes "ok so to solve the problem you use this magical incantation in Redux." Yes, I can adapt the magical incantation, but that doesn't really help me grok who owns which callback that makes which modifications or transformations to be consumed by which objects.
not saying you're taking offense to the critique, but I wouldn't. While I don't use Redux nor have experience with the docs for it, there have been some concepts that I didn't grasp from reading the docs for a topic where others had a better understanding of it coming out where after someone broke it down in a blog, it allowed me to understand it as well (at which point the docs were beneficial as a resource to come back to later). Different mediums will probably be better suited for getting more nuanced than the docs can, generally.
So I can totally see where conflicting feedback could appear and why you shouldn't take the "negative" feedback as a slight against the work on the docs (but fielding concerns/questions/suggestions as you are is completely a great thing).
From the outside looking in, if I were looking at Redux and I heard from a few "man, the docs are a bit hard to grasp" and others "I love the docs. They allowed me to get up and running" I wouldn't be scared off; it'd seem to be pretty par for the course.
Right, not taking offense - just saying that it's hard to come up with actionable ways to improve things when most people say they're good, and a few people say they're not helpful, and neither group really gives much in the way of specifics :)
The Udemy course that I saw gives an anology to how Redux is meant to work in the form of an Insurance Company and how Action Creators, Actions, Reducers, Stores etc. map to a real world scenario. That really helped my understanding of the 'Redux' model.
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...