Have you thought about using MobX instead? I think Redux's "complications" stem from guiding you towards a certain set of principles and ways of coding without giving you the tools to commit to those principles and ways of coding. Particularly, the way you compose reducers and the way you expose actions is manual and very boilerplate-ish.
Mark Erikson hosts a wonderful page full of redux ecosystem links, and here you can see all the tools to allow you to write and compose reducers - https://github.com/markerikson/redux-ecosystem-links/blob/ma... so clearly there was something missing there.
Redux as an idea I found very simple yet interesting. Watching Dan Abramov's series on building a Redux-lite from scratch helped changed my way of approaching how I build web apps.
However, using Redux in the mundane, daily sense was riddled with little practical niggles that were never really answered by the fairly minimalistic library, so I ended up with a kind of feeling that Redux kind of required me to "know" how to write good code before I commit to using it...
Meanwhile MobX seems to map to my mental model and all the modes of "mutation" that I'm already used to and have experience in, while also essentially introducing the same ideas as Redux.
I'm currently in the process of migrating a decently large React app from poorly written React/Flux to (hopefully) better written React/Redux, and I'm definitely feeling the lack of...useful examples. A ToDo list or showing lists of users from Github just doesn't cover the realistic complex problems well. Thus, when I encounter one of those problems, and Google fails me, I have to take a stab at it...and likely recreate the not-best-architectures of those that have done the same before me.
I'm still happy with Redux so far - the patterns it encourages is at least an improvement over the code from before, but I can't shake the the feeling that there are basic mistakes I'm making because I only have a handful of best practices goals.
Hi. My React/Redux links list [0] has a category for Redux architecture and best practices [1], with a ton of good info.
Also, the "Redux Tutorials" category has a "Project-Based Tutorials" section [2], which points to a number of tutorials that try to build _something_ in the process of teaching. Many of those tutorials are quite a bit more complex than yet another TodoMVC example. To pick out two specific examples:
- "Building a Simple CRUD App with React + Redux" [3] is an 8-part series that demonstrates building a CRUD app, including routing, AJAX calls, and the various CRUD aspect
- My own "Practical Redux" series [4] tries to demonstrate a number of intermediate to advanced React and Redux concepts in the context of a semi-meaningful-ish sample app.
Finally, my Redux addons list has a section listing a number of interesting React+Redux apps [5], both purpose-built examples and real world projects.
Hopefully that gives you some useful examples to work with. I'd also encourage you to drop by the Reactiflux chat channels on Discord to ask questions and get feedback, at https://www.reactiflux.com . Feel free to ping me on there!
In theory I like the basic ideas around redux, reducer composition is a very cool idea. However I really hate the implementation, the amount of boiler plate code is just too high.
If I had a nickel for every time I'd heard the "b" word... :)
FWIW, there's quite a few ways to reduce boilerplate with Redux, and you're welcome to use as many of them as you want. Variations on folder structures, action/constant definitions, reusable reducer logic, various abstraction layers... all kinds of stuff.
Would be interested to hear which particular pain points bother you.
Hey, somebody actually referenced my Redux addons list! Yay! :)
Yeah, there's a great quote someone posted in a Redux issue a couple months back that summarizes things well [0]:
> Redux is a generic framework that provides a balance of just enough structure and just enough flexibility. As such, it provides a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware.
So, there's a couple ways to think about things. One is that Redux is a very simple pattern that provides just enough structure to point you in a direction, and lets you figure out what specific approaches work best for your own situation. Another is that Redux is too generic, and doesn't provide enough guidance or built-in stuff for various use cases.
I've been one of Redux's maintainers since last summer, and I've definitely seen certain requests pop up repeatedly. For example, we frequently have issues or PRs filed asking if we can modify `combineReducers` to have built-in support for iterating over and updating Immutable.js Maps and Lists. We've also had requests for `cR` to pass down the root state as a third arg to reducers by default, or something similar.
These aren't _bad_ requests, and there's clearly some valid use cases there. However, one of the key principles of Redux is that _reducer logic is just functions_. The standard answer we've given for the most part is just that "`combineReducers` is only intended for the most common and basic use case, but you should feel free to write your own reducer logic for your own use case". So, in that sense, that large list of reducer-related utilities is actually a _good_ thing, because it means people _are_ building pieces that suit their needs.
FWIW, I personally have made a major effort to add documentation and write tutorials on a lot of the more practical issues Redux users face. I wrote the FAQ [1] and "Structuring Reducers" [2] sections for the docs, and have been writing a blog series called "Practical Redux" [3] that's intended to demonstrate some intermediate to advanced concepts in the context of a sample app.
If you have any particular pain points that you feel the docs do not currently address very well, please file an issue or a PR. I'm ALWAYS happy to work with anyone who wants to improve the docs.
As for Redux vs MobX, Preethi Kasireddy's presentation today was a FANTASTIC comparison of the relative strengths, weaknesses, tradeoffs, and use cases for each of them. I highly recommend that people check it out as soon as the ReactConf recordings are posted online. Also, my React/Redux links list [4] has a section that links to several other good MobX/Redux comparisons as well [5].
Hi! Got a couple pointers for you. First, my React/Redux links list [0] has links to many Redux tutorials of various kinds, as well as dozens of articles on Redux architecture, best practices, and useful techniques.
Second, if you've got questions, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. I'm an admin, and hang out there evenings US time, but there's always plenty of people happy to talk and answer questions. The invite link is at https://www.reactiflux.com .
Please feel free to ping me there if there's anything I can do to help!
This argument has been applied to virtually every framework or library at some point; the points and counterpoints rarely change and the result is inevitably to use right tool for your type AND scale of problem.
FWIW React's purpose is the opposite of what you said; it aims to make complex UI tasks simple by allowing you to compartmentalize your UI into isolated components.
If your UI isn't that complex or your application has very little state to manage then I could see how React would be overkill.
Would you like to share any reasons you believe that? Or at least which part you find unnecessarily complicated?
React exists out of a need to organize a complex system of interactions. Unless you understand what it's like to have to reel that sort of thing in, it's not going to be easy to wrap your head around quickly.