I dislike this attitude. That list is not exhausting, it's a list of specific tools that solve specific problems, if you don't have the problem don't concern yourself with the tool.
- I don't already understand how an app using redux works when it reaches a decent size; therefore don't know what problems it will have and need to learn more
- I can't start using redux to understand those problems without making important architectural choices early on, i.e. between sagas/thunks, ducks/not-ducks, or how to remove duplication from reducers, because the community has so many parallel solutions to any given problem; therefore, I need to write a toy app instead of using it on a real product
- redux on its own seems to need about ten packages before you can load information from a json api and pass it to react, a task which is the basis for most toy apps; therefore, every toy app I write seems bloated and heavyweight
It's a hard ecosystem to bootstrap yourself into.
I'm not sure why you say that "you need 10 packages to load JSON data". Assuming that you're in a browser that supports the Fetch API, you need _no_ additional packages at all. You can make an AJAX call in a connected component, and call `this.props.dispatch({type : "DATA_LOADED", payload : response.data})` in the success handler.
Now, we do encourage people to try moving that logic out of components to make it more reusable, which usually means using thunks. However, redux-thunk is all of 12-ish lines long, and if you'd prefer not to actually add it as a separate package, it can easily be pasted into your app directly. But, you genuinely shouldn't _need_ more packages than that to be making AJAX calls. There's plenty of additional abstractions that are available around making network requests and processing the results, but those are all purely optional.
Besides the other "discussion about abstraction" issue I just linked in another comment, I also recently opened up issues to discuss general docs improvements [0] and a rework of the "Ecosystem" page [1]. I really would like to have some docs sections that give more opinionated advice for topics such as "what side effects lib do I use?". Unfortunately, my own free time is already very limited, but I would _love_ to work with people from the community to add new docs sections and update the existing ones.
I also agree that there's a bit of a gap between the "TodoMVC" level and the "building a full-blown production app in the real world" level, in terms of docs and advice. I'd love to see some new docs sections that help with that aspect as well.
So, genuine request to you, and any other readers/Redux users out there: if you are interested in helping improve the Redux docs, PLEASE let me know! Ping me on Twitter or Reactiflux, file an issue, or leave a comment on an existing issue, and we can figure out how you can help us make the docs better and make it easier for people to level up along their Redux journey.
This sounds like a problem of inexperience (which is a problem everyone faces when using a new tool). If you've never used Rails, you're not going to understand the long term implications of maintaining and scaling a complex Rails application. If you want to know what problems you will encounter, you'll have to read a book or learn the hard way, the same as any other tool.
> I can't start using redux to understand those problems without making important architectural choices early on,
This means you're not experienced enough with redux to be making those choices and that's ok; use an alternative tool that you understand well, hire someone with the relevant experience, read a book, or understand that you'll have to do some refactoring later on if you make the wrong choices today.
> redux on its own seems to need about ten packages before you can load information from a json api and pass it to react, a task which is the basis for most toy apps; therefore, every toy app I write seems bloated and heavyweight
This is not correct, but also "not even wrong" in the sense that this concern is outside the scope of redux. If you want to use a bunch of redux related data packages that's fine, you're also free to use GraphQL, Backbone, fetch, jquery, webosckets or straight up XMLHttpRequest. When I hear "I need 100 packages just to do X" it's usually a sign to me that the developer is somewhat inexperienced with the ecosystem and tends to defer to a package whenever they need to solve a problem; this is usually the wrong approach, it's like someone complaining "I need 10 packages just to do string padding"... well no, you don't, just write that code yourself.
> It's a hard ecosystem to bootstrap yourself into.
So is cross-platform game programming and there are hundreds of different engines, toolkits, SDKs, editors and other utilities spread across a dozen different languages. Which one should you choose? I don't know it's all too confusing, they should just stop making new tools so I can catch up.
This is the fundamental problem. In order to learn Redux, you need experience with it. In order to get experience, you need to work with Redux. In order to work with Redux, you need to learn it.
You use the example of Rails, but Rails is the poster child of opinionated frameworks. For someone trying to learn it, there's no ambiguity about how a project is structured. The same is true of Unity or the UDK: there's a single tech choice to make, after which you can rely on the framework to guide you.
I understand that the js community prefers small composable libraries, and agree with the reasoning, but with Redux this is taken to extremes: a tiny core library, documentation that's mostly boilerplate, and much greater cognitive overhead than any other state management.
Also, as unofficial keeper of the Redux docs, I'd also appreciate any suggestions for improving them. Can you clarify what you mean by "documentation that's mostly boilerplate?
If you're looking for more of an "integrated" Redux experience, you might want to look at https://kea.js.org/ .
By boilerplate I mean that the docs are written using examples of e.g. a single network request and a handful of actions, where even a small application with a few repeated bits of code would introduce abstractions for common elements. Because the docs lay out the simplest possible way to do this, they don't fully represent a real app, and because the ecosystem is so vast, it's not obvious which abstractions are state-of-the-art.
Filling in the "next steps" tab with some hints about where to go would probably help a lot.
If you or anyone else reading would like to contribute writing that page, please leave a comment and let me know!
And yes, it's always tough to balance the various audiences and use cases when writing docs. Minimal examples like a TodoMVC can be helpful for showing off basic concepts and keeping a learner from getting too lost, but then those don't cover the complexities of a real-world app.
So strken, acemarke and others: Feel free to reply here, contact me on reactiflux (@mariusandra) or shoot me an e-mail if you feel like talking about Kea.
Cheers and thanks for all the nice words so far. :)
And you're welcome! I probably spend a bit too much more time answering questions than I really should, but hopefully it's helpful :)
It shouldn't be. If you don't like a tool, don't use it. Nobody is forcing you to use redux, you don't need it, even if you're building a complex react app, setState works just fine, seriously.
> The cognitive overhead of building and maintaining your own framework piecemeal can be detrimental to shipping code
So don't do that. Identify the problem, then use the tools that solve the problem, if you can't figure out which tool is the right one for the job that's your problem, not the fault of the tool. If I need to drill a hole in my wall I don't complain about how many drills are on the market, I just use the simplest tool to get the job done or hire someone who knows what they're doing
> especially if you don't have pragmatic and decisive leadership on your team.
The tool is not responsible for someone failing to use it correctly, that's absurd.
This is hand-waving to deflect Redux from legit criticisms, and is part of the reason I find both responses frustrating and unnecessarily dismissive.
You need to build your own framework for React SPAs because they're intentionally un-opinionated about the pieces you use. Just look at the scaffolding in place for create react app and all the various libraries. I would much rather solve real problems than discuss how to get Immutable to play nicely with Typescript or argue thinks vs. middleware.
"Get good" is a poor response to anyone wanting to see the wildly used/discussed state management solution for React get better, and implies that there aren't good devs out there with experience outside of JavaScript saying there is a better way.
You're right though - there are choices. I didn't like how the JavaScript ecosystem was progressing so I made a choice to not deal with it anymore professionally and it's been a very rewarding career change.
The comment I responded to is complaining that a list of tools makes them feel exhausted, that's not "legit criticism" that's low-effort whining. The legit criticism already received a response in the form of a list of tools meant to obviate the specific issues outlined by the critic, but somehow those tools being available is cynically characterized as a negative thing because some people don't know when or how to use those tools. That's their fault, not the tool's.
> You need to build your own framework for React SPAs because they're intentionally un-opinionated about the pieces you use
This is an engineering trade-off, it's not inherently wrong or bad; it's like whining that you have to spend time learning how and when to use a clutch when operating a manual transmission vehicle when an automatic would just figure it all out for you. Sorry, just because an automatic has a lower learning curve doesn't mean its a superior car, it's just a tradeoff, convenience over control.
> I would much rather solve real problems than discuss how to get Immutable to play nicely with Typescript or argue thinks vs. middleware.
So. Don't. Do. That.
You don't need those things to use React, that's a choice you're making because you apparently desire the features that those tools afford you as a developer, yet you're complaining because you don't like the consequences of the engineering decisions YOU made. I've written and deployed around eight React projects into production and while some of them use immutable.js, none of them use typescript because the team's experience with typescript is limited. You see that? We don't know how to use typescript... so we don't... and everything is fine.
> "Get good" is a poor response to anyone wanting to see the wildly used/discussed state management solution for React get better,
My response is not "get good", my response is quit complaining that tools exist that you don't like. You don't have to use them, especially in the React world where you get to pick and choose the tools that work best for you; if you find the choices overwhelming that's your fault, it's not the tools fault that it exists.
> and implies that there aren't good devs out there with experience outside of JavaScript saying there is a better way.
This is hilariously arrogant. People who don't work with JavaScript want to complain that there is a better way to do work in JavaScript. If there is a better way then put your keyboard where your mouth is and build something better rather than complaining about the existence of tools you don't like.