React itself is actually a pretty simple library. The problem is that it's not the whole story, so you need other bits and pieces to put together a functional SPA. Ender redux, react-router, etc. And because React tries to explicitly not be so opinionated about what you should use, the way you learn about this stuff is not from the official tutorial, but from various blog posts.
There are also resources like this: https://github.com/kriasoft/react-starter-kit. On the surface it's great. But for my taste it's organized very poorly. You have all your reusable (NB: reusable != reused) components in one place, and all your pages in another. Each component consists of exactly 3 files that are 3 directory levels down. Pages (views? containers?) are in a separate directory structure where each page consists of 3 files that are 3 directory levels down. I guess if your SPA consists of hundreds of pages/views/containers with most components reused many times this makes sense. For my applications (low dozens of pages/views/containers) this seems like a huge overkill.
And don't get me started on the redux theory of all global state all the time, which actually seems to not be ideal for things like "I just want a more complex <select>", and you have a very scattered learning curve.
By contrast, Vue has a pretty sane slightly opinionated learning curve. Sure, there are a few things you need to figure out (XHR/Websockets + VueX + promises don't have a decent recipe in the docs), but overall it's much more coherent.
You should use whatever file structure works best for you. "Folder-by-file-type" is common, as is "Folder-by-feature". My links list has a category discussing various project structures (), but that's completely up to you.
Redux's global state has tradeoffs. There's a lot of value in keeping your data outside the component tree (passing data between components that aren't directly related, making hot reloading easier, etc), as well as benefits to having a lot of logic be centralized (consistent handling of API responses, logging of dispatched actions). The tradeoff is that some aspects do become more complicated.
However, it's also important to note that YOU ARE NOT REQUIRED TO KEEP EVERY LAST BIT OF DATA IN REDUX!!!!! People have over-interpreted the phrase "single source of truth", and game-of-telephoned that to mean "You _must_ keep _all_ data in Redux". No. NOT true. Per the relevant Redux FAQ entry ():
> Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.
So, if it makes sense to keep a bunch of data for a <select> in the component that's rendering it, do so.
Finally, that "bits and pieces of info" aspect is exactly why I've put together my links list: to try to provide a single place that points a reasonably vetted selection of good info on React/Redux-related topics.
What I would love to see is one of those over-engineered React+whatever boilerplate project that shows you, in a step-by-step form, showing the evolution from a simple project to the final boilerplate they have, and why it exists like that.
I have created a fairly-large project in Redux, but as I created it I know that it wasn't the "optimal" way of architecting it.
So, before starting another project, I tried starting from the "react-redux-starter-kit" project, and it was immediately over my head. I have to instantly grok how they're using the router, layouts, stores (I thought Redux didn't use stores...), modules... the source even has explicit references to the way WebPack is going to lazily load stuff, so I don't even know if I could use some other build system without breaking the source.
I'd love to see the same project laid out as a series of refactorings:
1. Here we have a really simple Redux project, the way a beginner might code it
2. They realize they need routes. Let's refactor the code to include the router
3. The realize it would be better putting the related-components in their own folders. Here's that refactorization.
X. Look, your project now looks like the starter project!
I've seen a few sample repos that try to demonstrate the kind of thing you're talking about. Skimming through my links list, these look relevant: https://github.com/verekia/js-stack-from-scratch and https://github.com/Jordaanm/hipster-boilerplate . I think those are a bit more oriented at the build tooling side and not so much the application side, but they're close.
Also, the "React Tutorials" and "Redux Tutorials" categories (, ) in my links list both have a subsection labeled "Project-Based Tutorials", which points to articles that do have a more "build something meaningful"-type approach as opposed to just "here's concepts A, B, and C".
To call out one specific example: I have been writing a tutorial series on my own blog, called "Practical Redux" (). Rather than trying to teach the basics of React or Redux, it's intended to demonstrate a number of more intermediate and advanced concepts through building a sample app (one that's at least moderately more complex than yet another TodoMVC implementation). I'm not going to cover routing, because I've never done any client-side routing myself, but it _is_ kind of along the lines of what you're looking for. I describe the next piece I want to implement, link to the commit implementing that change, show some relevant diffs, and talk about the implementation. For example, I just published Part 6 today (), which demonstrates the "connected list" pattern and then discusses a number of important Redux performance guidelines to be aware of.
The official React tutorial is really basic and provides none of this guidance. The rest of the knowledge is scattered. You can discerne it eventually, but it takes lots of time, and often best practices change.
I am all for diversity of approaches, but there is no good starting point. So I spent days searching, comparing, etc.
Your list is great. It is not the only one. How do I know that yours is "correct"? The only answer is comparing which links show up frequently on various lists. That is so much more time consuming that having an official list or tutorial.
So, what would "authoritative" docs look like, given those wide varieties of use cases? The closest thing there is at the moment is the Create-React-App tool, which is deliberately opinionated about setting up a build tool system with certain behaviors, but is otherwise unopinionated about all other libraries and file structures you might choose to pull in.
The core React team is pretty small - currently like 7 people. They have to split their time between actually working on the library, and dealing with Facebook's internal needs. On top of that, the way Facebook uses React is going to be different than the way much of the community uses React, due to Facebook's unique and specific infrastructure.
For lists: yeah, there's some other useful lists out there. I actually point to them in the "Community Resources" category of my list. There was an issue discussing a possible new "Learning Resources" section for the React docs as part of the docs revamp ( https://github.com/facebook/react/pull/7117 ), which bogged down a bit due to concerns about endorsing specific libraries. There's currently an open issue regarding further additions to the docs that looks like a request for the community to contribute sections on specific topics ( https://github.com/facebook/react/issues/8060 ).
As for my own list: I put multiple hours into updating it every week, between reading articles, evaluating them, and categorizing them. I won't say I've read every word of every article, but I've definitely looked at each and every article in the list and determined that it's relevant and of good quality. Beyond that, I'd say that the nearly 6000 stars are a reasonable indicator that a lot of people are finding my list useful.
With the React ecosystem, it's basically equivalent to the Django template system having documentation, but the rest of the info being scattered across dozens of personal blogs.
The React team, being the face of the ecosystem, would do well to point newcomers to a list such as yours.