It is interesting how people have the idea that react === Redux/flux.
Where in fact Redux is unopinionated and works with other libraries/frameworks just fine.
How often do you see redux used with anything other than react? Or are you just talking about redux working with react alternatives like preact/inferno, etc?
You're not wrong, but practically 99% of people pair it with react.
The Redux pattern is used quite widely, even if not via the official library. See NGRX for example, which implements the pattern in TypeScript + Angular.
We use it in our native mobile applications (iOS / Android) for over a year now. It make a lot of sense, improved the codebase maintainability and reduced the number of bugs.
Redux is actually used noticeably outside of the React community.
Redux can be used with any UI layer, and there's bindings for many frameworks and UI layers besides React [0].
Redux has picked up popularity within the Angular community, both in its original form and the NgRx reimplementation. The ember-redux bindings are also starting to gain a bit of a following. Vue's VueX lib is inspired by Redux, and there's Vue-specific bindings for Redux itself.
People use it with Polymer (a lot of people in the community use it with polymer-redux package) and Vue.
React alternatives that you mentioned are also a thing.
Yeah it really is. I'm not sure where that comes from. Maybe it has something to do with the climate when React rose to popularity, where all the competing alternatives were "frameworks," and so people were in that mindset when they approached React?
In any case, it's led to a ton of confusion in the community, especially for newcomers.
There is a certain paradox with teaching something like Redux, in that it's designed to make complex systems easy to understand and manageable. Yet when trying to demonstrate with a simple example, it appears hugely over complex and unnecessary.
I think a pre-requisite to learning something like Redux (or any micro-architecture) is to first try building something without it. Once you understand the pains of undisciplined, organically designed, spaghetti applications, the cynicism is replaced by excitement over how this will improve your job/life/application.
This paradox I think is what turns people off Redux when they first learn it. "All this code... for what benefit?" Of course it's total overkill for something like a counter, or a todo list, but it's tough to teach an introduction to something by starting with "here's a huge enterprise app, let's dive in" :)
I tried to call this out in the article to make sure people are aware that improving simple Counter examples is not what Redux is really meant for.
I'm considering putting together a larger course/book that does just what you say - build up a React app using plain state until it becomes painful, and then refactor it to add Redux. My question right now is, how far should I go? Do I walk through building the entire app with state (and push through the complexity), or do I give up at the first indication that Redux would make things easier?
I understand the value of redux but I'd lump it in with git as an invaluable and elegant solution with a terrible interface. The structure is very confusing up front and makes no sense to an outsider. I learned react in about 15 minutes because it's so intuitive, but redux keeps making me scratch my head.
IMO, It's a fundamental flaw with JavaScript that interfaces aren't rigorous or discoverable and redux is a willing victim.
I think it's mostly react-redux. There's arcane boilerplate in the connect function, mapDispatchToProps looks like a leaky abstraction, actions being passed as objects with a string in them is super brittle.
I don't have a fix, but I think just being able to inject a link to the store and then having an API that can be manipulated directly from the component would more comprehensible and cut down on the layers of indirection. I typically see corresponding action, reducer js file for a component when 95% of the logic is already in the component. Just merge them.
Appreciate the feedback. Could you give specific examples of what you mean by "arcane boilerplate" and "leaky abstractions"? We don't have any plans to change the actual API, but I would genuinely be interested in any suggestions or concerns you have with it.
It's also worth noting that I personally highly recommend consistently writing separate action creator functions [0], and using the "object shorthand" argument to `connect` instead of writing a separate `mapDispatch` function.
That said, it also seems like part of what you're concerned with is the fundamental design of Redux. The use of plain object actions as a layer of indirection is deliberate [1], and it's what enables capabilities like time-travel debugging. Actions need to be serializable for that to work, and therefore strings are the best solution for the action's `type` field [2].
You certainly don't have to keep _everything_ in Redux. You should consider whether a given bit of state should live in Redux, or in a component's state [3]. But, if you _are_ going to keep data in Redux, then actions and reducers are necessary for the Redux data flow. They don't have to be in separate files [4], but they need to exist to update the store.
I guess it's a matter of taste, but using object shorthand for an API seems like and anti-pattern. APIs are where a rigorous definition is most valuable. Like I said, it works fantastically well once you get the hang of it, but try showing this to a newb and ask them to trace it. Nightmare.
I'm not being a grump either. I coded Perl professionally for over 5 years and am well-versed in terse, functional idioms, but the community rightfully decided that strings of punctuation were too obtuse for practical use.
This is exactly what happened to me and I'm glad I did it. My intro to programming was a nightmare jquery app. Then a slightly better Backbone app with too many Globals. Then an over engineered Sails app. And now a collection of React + Redux apps, multiple years old, each with increasing levels of maintainability.
I'm hesitant to see new programmers avoiding a "learn the hard way" project. Without it, there's so much they might never grok.
Just went through this myself, and that was exactly my experience. Really glad I spent time working with React so I knew what Redux would be great for before I tried to learn it.
> Once you understand the pains of undisciplined, organically designed, spaghetti applications, the cynicism is replaced by excitement over how this will improve your job/life/application.
Beautifully said. The same goes for schema-less data models. The full appreciation of foreign keys, data type validation, and check constraints doesn't kick in until you try incrementally changing a NoSQL spaghetti app.
Similarly, I've always liked javascript's dynamic and flexible nature, especially for ui programming where requirements evolve quickly and dramatically. But now that I've got a big redux app that is on a pretty steady course, I'm starting to see the value that static types would bring. A lot of the mental overhead of working with the codebase now consists of remembering the exact shape of all the data, which properties are defined on which actions, etc. Before too long I'm going to have to give Typescript, Flow, or something along those lines a serious look just for the sake of having it all defined in one place.
I've been singing the praises of Typescript since the first day I started playing with it. Easing into it from a JS codebase is pleasant enough, but greenfield development with typing everywhere is incredible. I highly encourage checking it out sooner rather than later.
I think there's a fair criticism of Redux in here - most well designed tools can accomodate a learning curve, and scale up the complexity when needed. I can be productive in Express without knowing about middleware, or git without knowing how to rebase.
Redux, on the other hand, expects you to dive into the deep end head first the first time you use it. I teach javascript development, and I'm noticing there's a pretty big gap where you're feeling the pain of React, but Redux is still too large a complexity tax (To be fair, even to an experienced programmer it often is - for every complex state change that warrants Redux there's 50 straightforward "change this field" or "toggle this boolean" actions.)
Maybe this isn't the responsibility of Redux, and something should be built on top of it, but there needs to be some amount of consensus on what the best solution is.
Yeah, personally I use it - I think it hits the sweet spot of making simple things simple while still allowing for complexity perfectly.
It's a shame I can't really teach it, however - the fact is, it doesn't have enough mindshare right now and part of the reason people take courses is to learn marketable skills. For better or for worse, nearly every React shop is looking for devs who know Redux.
I perhaps foolishly go ahead and teach React and Redux to my students. The first thing I show them, however, is this article by Dan Abramov, who you perhaps know from his conference videos or his amazing work fielding React bug reports.
It's downright embarrassing to walk through a Redux-using project with someone competent who's not immersed in the JS world. Source: had to do this recently. It helps if you translate "action creator", "action", and "reducer" to terms that are less misleading in the first two cases, and less uselessly-generic in the last one, but only a little.
I tolerate it for basically "no-one got fired for buying IBM" reasons, i.e. the devs I work with think it's good and it's better to have twice as many problems and none of them be my fault than half as many and all of them be my fault.
I would expand that to say, it's embarrassing/difficult to explain the JS ecosystem to experienced non-JS devs. From "why are there 132MB of packages for hello world?" to "why is there a build process at all", people outside the UI+JS world have a tough time seeing why there's so much complexity for "just the UI".
Also, side note, it's hilarious (and maybe telling) that we both referenced the "no-one got fired for buying IBM" quote...
As an old-school Java dev that's been pulled into the JS world kicking and screaming, I can say that I have a pretty good appreciation for most of the complexity around modern FE builds. NPM legitimately kinda sucked up until the last few releases and is now stabilizing. I get functional programming. I even advocated for react when it was new because it felt so natural and powerful. Redux (or really react-redux) just hasn't hit that sweet spot. That being said I've seen it be hugely successful on big projects.
The Redux learning curve is tough, especially for folks who don't already have a strong grasp of functional programming ideas. Immutability is weird. Breaking everything up into multiple places (dispatch, actions, reducers) is weird. Like you say, it's unfortunate that one must basically learn _all of it_ to get started using Redux. It does do a nice job of solving difficult problems though.
> there needs to be some amount of consensus on what the best solution is.
The thing is, there is consensus: it's Redux. I'm not saying that's good or bad, but it's king of the state management hill right now.
What's really interesting to me is that the JS community is largely allergic to anything that isn't the "best solution". Nobody wants to use a little library with 53 stars on Github, even if it's easier, or seems like a better fit than Redux. The thinking seems to be "It's not any good unless it's the most popular choice." Those sorts of libraries might be ok for proof-of-concept work, but not for the real world. Not for production.
What drives this line of thinking? I think it's complex, but I believe fear plays a big role.
- Fear of choosing the wrong library (what if it becomes unpopular!)
- Fear in one's own abilities to evaluate a library ("it seems fine to me, but I'm no authority, I can't make that call")
- Fear of looking bad to the boss ("Nobody ever got fired for buying IBM", right? React + Redux has that spot right now)
There's also the self-reinforcing nature of a popular thing: companies using Redux => job listings require Redux => people want to learn Redux => people make Redux courses/books/blogs => people don't teach the alternatives.
There's consensus on Redux - that's not what I'm talking about. There seems to be a fair amount of desire for something that simplifies "straightforward" state management. The Redux maintainers don't seem to be interested in this, preferring it to be something created by the community. As far as I can see though, no one is filling that gap.
I'm a Redux maintainer, and I'm _absolutely_ interested in making it easier for people to get started with Redux. I opened up an issue thread earlier this year to get community feedback and ideas on how we can do that: https://github.com/reactjs/redux/issues/2295 .
We don't plan to modify the Redux core itself, but I would _love_ to be able to list some tools as "approved" or "blessed" ways to get started easier.
Sadly, I just don't have enough free time to go build much of anything like that myself, but I will happily work with anyone in the community who's interested in doing so.
I also hope to revamp the Redux docs "Ecosystem" page to more specifically point to certain tools as recommended solutions to specific problems, but again haven't had time to do so yet.
Earlier this year, I opened up an issue to get community discussion and feedback on ways to "reduce boilerplate" and make the getting started experience easier: https://github.com/reactjs/redux/issues/2295
The discussion trailed off, but I'd love to get additional feedback and ideas on ways we can improve things and build easier-to-use abstractions on top of Redux. (Or, even better, get some volunteers to _help_ us build better tools for getting started.)
My only experience of using Redux was in a completely inappropriate application and I really came to hate it, but I can see how it'd be cool if you wanted to do like... a word processor or something where you wanted an undo/redo chain.
I agree with this. I tried to learn React and Redux a while back, and didn't really grok it, so I built the React app without Redux. Ended up passing state up and down many, many layers of components and it got pretty hairy. So I added Redux to the mix and it was like a lightbulb went off in my head.
That's because you used React Router, which makes the router a view component. Router should be independent of view technology. If you had used React in the MVC style you would not have had to use Redux. Think about how session state works in the case of server-side applications. The same can be done on the client side too, by using React with an MVC framework.
Think about how MVC works in iOS, or ASP.NET MVC or JSP Model 2, etc. In the case of the latter two, your state is stored in the session as simple, regular objects. Have you felt the need for actions and reducers and immutability etc. when using session state? I have not.
When programming JavaScript SPA, you can program in the style of MVC also. There is no need for actions, reducers and so on, unless your app is for example a word processor and you need undo/redo (as mentioned by another comment on this thread.) Most of the time you are getting data from the backend, temporarily storing stuff in memory, modifying it and sending it back to the backend. There is no need for actions/reducers and such other nonsense for that.
When I mention this someone always points me to the "you may not need redux" article by the creator of redux, in an attempt to legitimize some use cases of redux. There may indeed be some legitimate uses cases for redux. But it has become the de facto standard way of building React applications, and that's totally unjustified.
MVC isn't especially easier than event sourcing (which is basically what redux is) once you get to larger applications. I think the two map quite nicely onto Fowler's design stamina theory (https://martinfowler.com/bliki/images/designStaminaGraph.gif) in that redux is harder to work with for small apps but the complexity scales linearly. MVC is easy for small apps but has a tendency towards spaghetti in larger codebases.
>> MVC is easy for small apps but has a tendency towards spaghetti in larger codebases.
Disagree. There is no reason to believe MVC tends towards spaghetti in large codebases. Controllers and views implement a small portion of the application's functionality. When the applications get larger individual controllers and views do not even know that the application got larger, so this scales very well.
It scales well in theory, and as long as the devs understand separation of concerns, and keep on top of refactoring, and don't overcomplicate things with extra layers of abstraction.
I've worked on some Angular (1) apps that became very messy over time. I think it all depends on the project. React/Redux can get messy too.
the things I find scale badly in MVC are primarily related to general OOP scalability issues - dependency hell, bloated classes, loss of separation of concern, and the big one being poor cohesion and state mutation propagation. I think my argument is broadly more like "OOP is needlessly hard", something that isn't really inherent to MVC.
It doesn't because encapsulated mutation does not compose. Typical example: your data model fires signals notifying change as soon as you change them, then thew view updates. All good, until you have to build transactional updates and then you get flicker, broken invariants due to partial values being propragated, etc, etc. You need to understand how everything is wired up together to really know what is going on because effects are interleaved with logic, even when each component individually feels decoupled and nice.
What Redux/value-based data model does is to really separate those concerns. Your update logic is a function that just can mess all it wants with the new values it produces. It is composable because you can just build logic by calling smaller logical unit and you know everything you need to know by looking at the inputs and outputs.
It is way simpler (and less!) code in all but the most trivial of the examples.
If your model layer objects are firing events you have problems already because it obscures the call graph. I try to avoid that style. The controller should update the model objects, then if a view update is needed it should be triggered by the controller not the model layer object.
Then your controller needs to know about 1) all existing views and 2) all effects of model update logic. Again, you end up with low decoupling with points that you can only change with global knowledge (and lots of potential effect interleaving). If you already have a "plain data" model, the next logical step is to just get rid of stateful controller and use a simple data-flow Redux-like flow for updating the UI.
I give in that the tricky part is finding UI frameworks that play nicely. You need something React-like to efficiently re-evaluate the Model -> UI functions, or use an immediate-mode API. Alternatively one can manually write some function to update a stateful UI by comparing the previous and current model and often it's enough. It is a bit like your controller but it is agnostic to the specific actions that happened but just look at the model changes (i.e. no global knowledge needed). I recently discussed this here:
We were precisely talking about composition and now you say there is only one? I guess you are talking about small apps where you have small dedicated views?
That is a very narrow definition of MVC. I am talking of large interactive software with multiple views on large hierarchical data trees data with different levels of focus and granularity. The kind of software I am thinking of big programs like Photoshop, Premiere, an IDE, Ableton Live...
Disclaimer: I worked for Ableton for quite a 5 few years, and have spent most of my career building interactive software (I work as independent consultant now). Most of the software of that time and age is built around MVC. It kinda works, but as a lot of people in the industry building software of that size will tell you: scale brings the the pain. Because of composoability. In the C++ world, see also talks from Sean Parent--who worked on Photoshop--and is also a strong proponent of "value-based" approaches (he is a great source of inspiration for me). Sean claims that something like 70% of bugs in Photoshop are in UI-related code typical MVC wiring up stuff.
In the end, just pick the right tool for the job. If you are writing small apps and MVC does not explode at that size and fits nicely with the underlying frameworks, go ahead and use it (I strongly suspect you are an iOS dev and understand how conformity with the native framworks is very important there).
But if you are building something large, highly interactive, with lots of views and concurrency, try to move to a more declarative/unidirectional flow/functional approach. It is still an open field and there are many alternative approaches, but it builds down to composability, denotational reasoning and decoupling of effects/logic.
@arximboldi, I wouldn't use MVC for implementing something like Photoshop or and IDE, that's not the kind of application MVC is good for. MVC works well for applications that navigate through multiple screens.
Yea basically this. Built a 'big data app' using Ember, which was all well and fine until some of the routes essentially became their own apps, that were more akin to apps like photoshop. MVC really broke down for us here, and it wasn't until we introduced react / redux and slowly refactored the application until things got more manageable and sane.
OOP was very different in smalltalk too. Industry software dev has really strayed away from the theoretical origins it was based in, although I think the tide is starting to turn back now.
Agreed! Redux is cool but often overkill for basic CRUD apps, which the majority of JavaScript SPAs tend to be. My approach has been to take a long look at the app structure - if there's a way to refactor it to remove Redux (or what have you), that's probably the most sensible thing to do. Simple code > clever code where performance and maintainability are concerned.
I wouldn't mind a use case where Redux would be necessary or at least beneficial, for the practice, but I've yet to run across it after building half a dozen or more SPAs. These would be enterprise SPAs used in production, btw.
Hey, this is a bit tangental but since you mention building enterprise SPAs I'll guess your experience will be able to help me. So, I'm not as experienced but can get around to learning any code and as I need to start building a portfolio I dove in again to build one. But things were breaking and I couldn't get rolling as fast I thought and although for a longer term bigger project I would spend the time tweaking I want to get something up fast and thought that I need to use a simpler tool. So, I'm curious what to you use to build your SPAs? What's the process like for you? Thanks
In the apps that I've built, having many components manage their own private state makes it hard to coordinate said components, because all of the application state is stuffed inside different jars that you can't easily peak into.
It's been much easier to pull all app state into a central, db like structure, and allow components to connect and query that structure for whatever data they need. It makes making changes to components in the future easier, because all of my data is normalized in a structure, and it's all possibly available to any component in the app.
I've found that with MVC, if you design the private state a certain way, and in the future need largeish independent components to coordinate, well, you're going to have a bad time.
So redux or not, I'm definitely a fan managing state as it's own separate thing, and having components able to query and connect to that data structure, without having to pipe props down a tree of components, which leads to an app that's hard to change.
I think the main problem is that MVCs aren't really a good way to write interfaces. You have so many state values that needs to be stored somewhere (dropdowns, input values etc). I'm not saying that redux is a good use-case everywhere but trying to write MVCs on the web is not a good fit. React is not a MVC library and not only the view part of it either...
What this will let you do is basically extend your server-side GraphQL API with a set of local resolvers for queries and mutations, and let you query and mutate both your server-side and client-side state using a single consistent API (GraphQL, with client-side fields decorated with a @client directive), backed by a (mostly) automatically normalized local state cache (by default apollo-cache-inmemory, but customizable, so you can even implement a Redux based cache if you'd like more control).
A lot of the complexity in Redux today stems from the need to reconcile client-side state with server-side state, usually fetched through some kind of async actions paradigm like Thunks+Promises, Saga, Observables, etc, to be then manually merged into the local state after being transformed into a normalized form.
I personally think one of the biggest problems with the design of Redux is that the architecture derives most of its benefits from having a normalized state tree, but it also makes it all too easy for developers to store non-normalized data in the state tree. Although admittedly an architecture that does enforce a normalized state tree would be an order of magnitude more difficult to learn and work with in the wild-west of RESTful APIs that used to be the de-facto norm back in the days when it was designed (and it still is, though that may be slowly changing with the rapid adoption of GraphQL), where most server-side data you receive isn't easily normalizable to begin with.
A good GraphQL client like Apollo can already abstract away much of the complexity involved with async server requests through its Higher-Order Component-based API, which simply provides data to the wrapped component as props, so it doesn't need to know how to fetch that data. More importantly though, Apollo also ensures that all the server-side state it maintains in its cache is stored in a normalized manner, and GraphQL makes this fairly easy.
Apollo-link-state goes a step further and allows you to use the same abstractions for managing client-only state, and store it in a normalized form alongside your server-side state, to allow for a much more consistent and comprehensive state management API.
With all that said, apollo-link-state is still really young and I've only played around with it briefly in toy projects, so there's no guarantee it could scale as well to large teams as Redux has. I do still personally find it to be one of the most promising alternatives out there though.
Lastly, Relay Modern also supposedly has something called Client Schema Extensions, which I assume is similar to apollo-link-state, but wasn't able to find any documentation on it outside of a brief mention in its release notes: https://facebook.github.io/relay/docs/new-in-relay-modern.ht...
I appreciate the author's work to explain this, and I like starting without Redux as a demonstration - definitely a good idea to figure out what React does on its own first.
That said, I found the reverse approach to Redux to be more confusing than the actual Redux documentation and the tutorials that Dan Abramov has already put together around Redux which explains things quite lucidly.
Second - it's interesting you found the reverse approach to be confusing. I've heard from multiple people that loved it and said it made more sense to them that way. Different strokes and all that!
How experienced were you as a dev before you read the Redux docs + Dan's tutorials? I ask because I learned with those too, and they made sense to me (Dan's egghead videos were eye-opening), and I've been doing software for > 10 years professionally... but my suspicion is most beginners don't do as well with the top-down approach.
Hi there and thanks for the response. Certainly not a beginner - been working in the field awhile and I'd worked previously with app frameworks like Angular and a written a number of other less "frameworky" apps before that. Could be an indicator as you mention :)
The thing I found so compelling about Redux was thinking about state being immutable unless you took the original state {...} and changed with a reducer, which was called depending on the action you want to take. At that point, when something is changed, the whole app is changed - it's the one thing to rule them all. If you want to change something, you need to take action. "How do you change state?" "Take an action."
Without understanding that flow up front it was hard to determine _why_ one would need to do things like connect, createStore, etc and how state magically got to be a prop.
I think your walk-through does a great job of explaining things step by step starting from the react code (and what Redux replaces) and I can see it working well for a number of learning styles. I also really like the pancake syrup provider imagery.
Dan's teaching style is very much "from first principles". You can see that in his Egghead videos, as well as the "Middleware" page in the Redux docs [0].
I've seen feedback that Dan's teaching style is the greatest thing ever, and feedback that it requires a giant leap of faith that "we write thing A, and thing B, and thing C, and magically they all work together at the end". Clearly, different people have different learning styles. Dan and Andrew _did_ try to write the docs in a way that would be accessible for people with varying backgrounds, but it's tough to write docs in a way that works for everyone.
If you or anyone else has suggestions for improving the docs, please let me know! I'm always open to ideas for improvements. Please ping me on Twitter at @acemarke, or file an issue / PR in the repo.
Yeah - I can see that. "It's all functions so it all works" haha. I think the context setter that helped for me was to see "hey here's what I see with state, and here's how I think about it and did the thing" at React EU: https://www.youtube.com/watch?v=xsSnOQynTHs
Switched our entire native app stack to a redux backend (Swift and Kotlin), never been happier. Sure there is more code in the end, but the decoupling and simplicity to use is just too good.
Especially on iOS when you know how complex it is to maintain a controller hierarchy with a (now dead) dependency chain.
Like the explanation a lot. Even when you've understood redux, and want to use, the amount of upfront boilerplate can be a turn off. I liked this approach of parsing out the boilerplate piece by piece.
It’s ES6 JavaScript, it’s great, and most modern browsers support it out of the box. You can also use Babel to transpire it into something that’s supported everywhere.
I'm a Redux maintainer, and this is a great introduction to Redux. I love Dave's ability to break things down into easily understandable pieces, and his clear writing style.
I also saw a similar "React and Redux: An Introduction" tutorial published just within the last couple days [0].
For anyone who's looking to learn more about Redux, I'd encourage you to check out my React/Redux links list [1], which has sections pointing to more Redux tutorials [2], Redux architecture and best practices [3], and much more.
If you've picked up the basics of Redux and want to see how it works at a larger scale, I recommend the "Building a Simple CRUD App with React and Redux" series [4], and my own "Practical Redux" tutorial series [5].
Also, my "Idiomatic Redux" blog series [6] looks at things like the history and intent behind Redux, common usage patterns and why they exist, and why I consider certain patterns to be the "right" way to use Redux.
Finally, I am always happy to answer questions about learning and using React and Redux! Please feel free to ping me on Twitter at @acemarke. Also, come by the Reactiflux chat channels on Discord [7]. There's always plenty of people around who can answer questions. I'm usually on there evenings US time.
That said, I'm already very busy just trying to keep up with the React+Redux community, and don't have time to keep tabs on everything that's going on in the Angular world as well. If you do find any kind of similar collection that's more focused on Angular+Redux, please let me know!
Nice thing about this architecture is that it really is agnostic to your stack and as long as you have some way to build "values" you are good to go.
I have recently been working on a Redux for C++ experimental library with time-travel and all. As an example I built a mini-emacs text-editor with it. Should post about it here whenever I flesh out the README and all (or the MeetingCpp talk about it gets published). In the meantime you might want to check these links:
Lin Clark's cartoons are always excellent, but these articles serve different purposes. "A Cartoon Intro to Redux" is more about the conceptual aspects, while Dave's post is both concepts and actual code usage.
83 comments
[ 2.4 ms ] story [ 133 ms ] threadYou're not wrong, but practically 99% of people pair it with react.
https://github.com/search?utf8=%E2%9C%93&q=angular+redux&typ...
https://github.com/ngrx/platform
Redux can be used with any UI layer, and there's bindings for many frameworks and UI layers besides React [0].
Redux has picked up popularity within the Angular community, both in its original form and the NgRx reimplementation. The ember-redux bindings are also starting to gain a bit of a following. Vue's VueX lib is inspired by Redux, and there's Vue-specific bindings for Redux itself.
[0] https://github.com/markerikson/redux-ecosystem-links/blob/ma...
In any case, it's led to a ton of confusion in the community, especially for newcomers.
I think a pre-requisite to learning something like Redux (or any micro-architecture) is to first try building something without it. Once you understand the pains of undisciplined, organically designed, spaghetti applications, the cynicism is replaced by excitement over how this will improve your job/life/application.
I tried to call this out in the article to make sure people are aware that improving simple Counter examples is not what Redux is really meant for.
I'm considering putting together a larger course/book that does just what you say - build up a React app using plain state until it becomes painful, and then refactor it to add Redux. My question right now is, how far should I go? Do I walk through building the entire app with state (and push through the complexity), or do I give up at the first indication that Redux would make things easier?
I'd love to see a complete project that uses redux, and would be horrible without it. Any pointers?? :)
https://github.com/devtools-html/debugger.html
- An 8-part "Build a Simple CRUD App with React and Redux" tutorial: http://www.thegreatcodeadventure.com/building-a-simple-crud-...
- My own "Practical Redux" tutorial series, which shows off specific useful React and Redux techniques within a sample app: http://blog.isquaredsoftware.com/series/practical-redux/
Also, my Redux addons catalog has a page listing many other interesting Redux-based apps, including purpose-built samples and real-world apps: https://github.com/markerikson/redux-ecosystem-links/blob/ma...
IMO, It's a fundamental flaw with JavaScript that interfaces aren't rigorous or discoverable and redux is a willing victim.
Is this a concern with docs, the core Redux store API, the React-Redux API, or something else? Any suggestions for how we can improve things?
I don't have a fix, but I think just being able to inject a link to the store and then having an API that can be manipulated directly from the component would more comprehensible and cut down on the layers of indirection. I typically see corresponding action, reducer js file for a component when 95% of the logic is already in the component. Just merge them.
It's also worth noting that I personally highly recommend consistently writing separate action creator functions [0], and using the "object shorthand" argument to `connect` instead of writing a separate `mapDispatch` function.
That said, it also seems like part of what you're concerned with is the fundamental design of Redux. The use of plain object actions as a layer of indirection is deliberate [1], and it's what enables capabilities like time-travel debugging. Actions need to be serializable for that to work, and therefore strings are the best solution for the action's `type` field [2].
You certainly don't have to keep _everything_ in Redux. You should consider whether a given bit of state should live in Redux, or in a component's state [3]. But, if you _are_ going to keep data in Redux, then actions and reducers are necessary for the Redux data flow. They don't have to be in separate files [4], but they need to exist to update the store.
[0] http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why...
[1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
[2] https://redux.js.org/docs/faq/Actions.html#actions-string-co...
[3] https://redux.js.org/docs/faq/OrganizingState.html#organizin...
[4] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
I'm not being a grump either. I coded Perl professionally for over 5 years and am well-versed in terse, functional idioms, but the community rightfully decided that strings of punctuation were too obtuse for practical use.
I'm hesitant to see new programmers avoiding a "learn the hard way" project. Without it, there's so much they might never grok.
Beautifully said. The same goes for schema-less data models. The full appreciation of foreign keys, data type validation, and check constraints doesn't kick in until you try incrementally changing a NoSQL spaghetti app.
Redux, on the other hand, expects you to dive into the deep end head first the first time you use it. I teach javascript development, and I'm noticing there's a pretty big gap where you're feeling the pain of React, but Redux is still too large a complexity tax (To be fair, even to an experienced programmer it often is - for every complex state change that warrants Redux there's 50 straightforward "change this field" or "toggle this boolean" actions.)
Maybe this isn't the responsibility of Redux, and something should be built on top of it, but there needs to be some amount of consensus on what the best solution is.
It's a shame I can't really teach it, however - the fact is, it doesn't have enough mindshare right now and part of the reason people take courses is to learn marketable skills. For better or for worse, nearly every React shop is looking for devs who know Redux.
You might not need Redux:
https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
The little example he provides is remarkably powerful and a great intro to thinking like a Redux programmer.
I tolerate it for basically "no-one got fired for buying IBM" reasons, i.e. the devs I work with think it's good and it's better to have twice as many problems and none of them be my fault than half as many and all of them be my fault.
Also, side note, it's hilarious (and maybe telling) that we both referenced the "no-one got fired for buying IBM" quote...
Having come from cross-plat C++, the JS build system(s) are impressing me, at least the one around React Native.
One data point. :)
> there needs to be some amount of consensus on what the best solution is.
The thing is, there is consensus: it's Redux. I'm not saying that's good or bad, but it's king of the state management hill right now.
What's really interesting to me is that the JS community is largely allergic to anything that isn't the "best solution". Nobody wants to use a little library with 53 stars on Github, even if it's easier, or seems like a better fit than Redux. The thinking seems to be "It's not any good unless it's the most popular choice." Those sorts of libraries might be ok for proof-of-concept work, but not for the real world. Not for production.
What drives this line of thinking? I think it's complex, but I believe fear plays a big role.
- Fear of choosing the wrong library (what if it becomes unpopular!)
- Fear in one's own abilities to evaluate a library ("it seems fine to me, but I'm no authority, I can't make that call")
- Fear of looking bad to the boss ("Nobody ever got fired for buying IBM", right? React + Redux has that spot right now)
There's also the self-reinforcing nature of a popular thing: companies using Redux => job listings require Redux => people want to learn Redux => people make Redux courses/books/blogs => people don't teach the alternatives.
- More popular libraries are better maintained and have more support
- More people use them (obviously), so more problems will already have already been solved the ${library} way
- Much easier to hire developers who know the more popular libraries
We don't plan to modify the Redux core itself, but I would _love_ to be able to list some tools as "approved" or "blessed" ways to get started easier.
Sadly, I just don't have enough free time to go build much of anything like that myself, but I will happily work with anyone in the community who's interested in doing so.
I also hope to revamp the Redux docs "Ecosystem" page to more specifically point to certain tools as recommended solutions to specific problems, but again haven't had time to do so yet.
The discussion trailed off, but I'd love to get additional feedback and ideas on ways we can improve things and build easier-to-use abstractions on top of Redux. (Or, even better, get some volunteers to _help_ us build better tools for getting started.)
Which it is, actually!
Think about how MVC works in iOS, or ASP.NET MVC or JSP Model 2, etc. In the case of the latter two, your state is stored in the session as simple, regular objects. Have you felt the need for actions and reducers and immutability etc. when using session state? I have not.
When programming JavaScript SPA, you can program in the style of MVC also. There is no need for actions, reducers and so on, unless your app is for example a word processor and you need undo/redo (as mentioned by another comment on this thread.) Most of the time you are getting data from the backend, temporarily storing stuff in memory, modifying it and sending it back to the backend. There is no need for actions/reducers and such other nonsense for that.
When I mention this someone always points me to the "you may not need redux" article by the creator of redux, in an attempt to legitimize some use cases of redux. There may indeed be some legitimate uses cases for redux. But it has become the de facto standard way of building React applications, and that's totally unjustified.
Disagree. There is no reason to believe MVC tends towards spaghetti in large codebases. Controllers and views implement a small portion of the application's functionality. When the applications get larger individual controllers and views do not even know that the application got larger, so this scales very well.
I've worked on some Angular (1) apps that became very messy over time. I think it all depends on the project. React/Redux can get messy too.
It doesn't because encapsulated mutation does not compose. Typical example: your data model fires signals notifying change as soon as you change them, then thew view updates. All good, until you have to build transactional updates and then you get flicker, broken invariants due to partial values being propragated, etc, etc. You need to understand how everything is wired up together to really know what is going on because effects are interleaved with logic, even when each component individually feels decoupled and nice.
What Redux/value-based data model does is to really separate those concerns. Your update logic is a function that just can mess all it wants with the new values it produces. It is composable because you can just build logic by calling smaller logical unit and you know everything you need to know by looking at the inputs and outputs.
It is way simpler (and less!) code in all but the most trivial of the examples.
I give in that the tricky part is finding UI frameworks that play nicely. You need something React-like to efficiently re-evaluate the Model -> UI functions, or use an immediate-mode API. Alternatively one can manually write some function to update a stateful UI by comparing the previous and current model and often it's enough. It is a bit like your controller but it is agnostic to the specific actions that happened but just look at the model changes (i.e. no global knowledge needed). I recently discussed this here:
https://github.com/arximboldi/lager/issues/1#issuecomment-34...
That is a very narrow definition of MVC. I am talking of large interactive software with multiple views on large hierarchical data trees data with different levels of focus and granularity. The kind of software I am thinking of big programs like Photoshop, Premiere, an IDE, Ableton Live...
Disclaimer: I worked for Ableton for quite a 5 few years, and have spent most of my career building interactive software (I work as independent consultant now). Most of the software of that time and age is built around MVC. It kinda works, but as a lot of people in the industry building software of that size will tell you: scale brings the the pain. Because of composoability. In the C++ world, see also talks from Sean Parent--who worked on Photoshop--and is also a strong proponent of "value-based" approaches (he is a great source of inspiration for me). Sean claims that something like 70% of bugs in Photoshop are in UI-related code typical MVC wiring up stuff.
In the end, just pick the right tool for the job. If you are writing small apps and MVC does not explode at that size and fits nicely with the underlying frameworks, go ahead and use it (I strongly suspect you are an iOS dev and understand how conformity with the native framworks is very important there).
But if you are building something large, highly interactive, with lots of views and concurrency, try to move to a more declarative/unidirectional flow/functional approach. It is still an open field and there are many alternative approaches, but it builds down to composability, denotational reasoning and decoupling of effects/logic.
Since then a lot of different things have been called MVC..
I wouldn't mind a use case where Redux would be necessary or at least beneficial, for the practice, but I've yet to run across it after building half a dozen or more SPAs. These would be enterprise SPAs used in production, btw.
https://github.com/kriasoft/react-starter-kit
Redux-friendly, too.
It's been much easier to pull all app state into a central, db like structure, and allow components to connect and query that structure for whatever data they need. It makes making changes to components in the future easier, because all of my data is normalized in a structure, and it's all possibly available to any component in the app.
I've found that with MVC, if you design the private state a certain way, and in the future need largeish independent components to coordinate, well, you're going to have a bad time.
So redux or not, I'm definitely a fan managing state as it's own separate thing, and having components able to query and connect to that data structure, without having to pipe props down a tree of components, which leads to an app that's hard to change.
What this will let you do is basically extend your server-side GraphQL API with a set of local resolvers for queries and mutations, and let you query and mutate both your server-side and client-side state using a single consistent API (GraphQL, with client-side fields decorated with a @client directive), backed by a (mostly) automatically normalized local state cache (by default apollo-cache-inmemory, but customizable, so you can even implement a Redux based cache if you'd like more control).
A lot of the complexity in Redux today stems from the need to reconcile client-side state with server-side state, usually fetched through some kind of async actions paradigm like Thunks+Promises, Saga, Observables, etc, to be then manually merged into the local state after being transformed into a normalized form.
I personally think one of the biggest problems with the design of Redux is that the architecture derives most of its benefits from having a normalized state tree, but it also makes it all too easy for developers to store non-normalized data in the state tree. Although admittedly an architecture that does enforce a normalized state tree would be an order of magnitude more difficult to learn and work with in the wild-west of RESTful APIs that used to be the de-facto norm back in the days when it was designed (and it still is, though that may be slowly changing with the rapid adoption of GraphQL), where most server-side data you receive isn't easily normalizable to begin with.
A good GraphQL client like Apollo can already abstract away much of the complexity involved with async server requests through its Higher-Order Component-based API, which simply provides data to the wrapped component as props, so it doesn't need to know how to fetch that data. More importantly though, Apollo also ensures that all the server-side state it maintains in its cache is stored in a normalized manner, and GraphQL makes this fairly easy.
Apollo-link-state goes a step further and allows you to use the same abstractions for managing client-only state, and store it in a normalized form alongside your server-side state, to allow for a much more consistent and comprehensive state management API.
With all that said, apollo-link-state is still really young and I've only played around with it briefly in toy projects, so there's no guarantee it could scale as well to large teams as Redux has. I do still personally find it to be one of the most promising alternatives out there though.
Lastly, Relay Modern also supposedly has something called Client Schema Extensions, which I assume is similar to apollo-link-state, but wasn't able to find any documentation on it outside of a brief mention in its release notes: https://facebook.github.io/relay/docs/new-in-relay-modern.ht...
> Dan Abramov, just now : "if you want to teach someone why to use an abstraction, you should first make them feel the pain of not having it"
But yes, it's tough to try to show the value of Redux while at the same time keeping the example simple enough to illustrate the basic mechanics.
That said, I found the reverse approach to Redux to be more confusing than the actual Redux documentation and the tutorials that Dan Abramov has already put together around Redux which explains things quite lucidly.
Example: https://egghead.io/lessons/react-redux-the-single-immutable-...
Second - it's interesting you found the reverse approach to be confusing. I've heard from multiple people that loved it and said it made more sense to them that way. Different strokes and all that!
How experienced were you as a dev before you read the Redux docs + Dan's tutorials? I ask because I learned with those too, and they made sense to me (Dan's egghead videos were eye-opening), and I've been doing software for > 10 years professionally... but my suspicion is most beginners don't do as well with the top-down approach.
The thing I found so compelling about Redux was thinking about state being immutable unless you took the original state {...} and changed with a reducer, which was called depending on the action you want to take. At that point, when something is changed, the whole app is changed - it's the one thing to rule them all. If you want to change something, you need to take action. "How do you change state?" "Take an action."
Without understanding that flow up front it was hard to determine _why_ one would need to do things like connect, createStore, etc and how state magically got to be a prop.
I think your walk-through does a great job of explaining things step by step starting from the react code (and what Redux replaces) and I can see it working well for a number of learning styles. I also really like the pancake syrup provider imagery.
I've seen feedback that Dan's teaching style is the greatest thing ever, and feedback that it requires a giant leap of faith that "we write thing A, and thing B, and thing C, and magically they all work together at the end". Clearly, different people have different learning styles. Dan and Andrew _did_ try to write the docs in a way that would be accessible for people with varying backgrounds, but it's tough to write docs in a way that works for everyone.
If you or anyone else has suggestions for improving the docs, please let me know! I'm always open to ideas for improvements. Please ping me on Twitter at @acemarke, or file an issue / PR in the repo.
[0] https://redux.js.org/docs/advanced/Middleware.html
[1] https://github.com/reactjs/redux/pull/140#issuecomment-11371...
[2] https://twitter.com/dan_abramov/status/622568094939090944
I also saw a similar "React and Redux: An Introduction" tutorial published just within the last couple days [0].
For anyone who's looking to learn more about Redux, I'd encourage you to check out my React/Redux links list [1], which has sections pointing to more Redux tutorials [2], Redux architecture and best practices [3], and much more.
If you've picked up the basics of Redux and want to see how it works at a larger scale, I recommend the "Building a Simple CRUD App with React and Redux" series [4], and my own "Practical Redux" tutorial series [5].
Also, my "Idiomatic Redux" blog series [6] looks at things like the history and intent behind Redux, common usage patterns and why they exist, and why I consider certain patterns to be the "right" way to use Redux.
Finally, I am always happy to answer questions about learning and using React and Redux! Please feel free to ping me on Twitter at @acemarke. Also, come by the Reactiflux chat channels on Discord [7]. There's always plenty of people around who can answer questions. I'm usually on there evenings US time.
[0] http://jakesidsmith.com/blog/post/2017-11-18-redux-and-react...
[1] https://github.com/markerikson/react-redux-links
[2] https://github.com/markerikson/react-redux-links/blob/master...
[3] https://github.com/markerikson/react-redux-links/blob/master...
[4] http://www.thegreatcodeadventure.com/building-a-simple-crud-...
[5] http://blog.isquaredsoftware.com/series/practical-redux/
[6] http://blog.isquaredsoftware.com/series/idiomatic-redux/
[7] https://www.reactiflux.com
That said, I'm already very busy just trying to keep up with the React+Redux community, and don't have time to keep tabs on everything that's going on in the Angular world as well. If you do find any kind of similar collection that's more focused on Angular+Redux, please let me know!
I have recently been working on a Redux for C++ experimental library with time-travel and all. As an example I built a mini-emacs text-editor with it. Should post about it here whenever I flesh out the README and all (or the MeetingCpp talk about it gets published). In the meantime you might want to check these links:
The library: https://github.com/arximboldi/lager
The Counter-Example: https://github.com/arximboldi/lager/tree/master/example/coun...
The text editor: https://travis-ci.org/arximboldi/ewig
Show-case of a time-travelling debugger: https://twitter.com/sinusoidalen/status/926382341433577472
If Dave's post was scoped to optimizing redux implementation, detailed code samples would be appropriate.