Redux – Not Dead Yet
blog.isquaredsoftware.com
blog.isquaredsoftware.com
What most people want is an easy way to pass down state to nested components, but the context API is a bit verbose and otherwise you end up with the props-drilling problem, passing and passing and passing.
Problem is, Redux and MobX solve far more than this problem and in the end you are stuck with all the complexity they add, even if you don't need the other benefits they bring.
In 80% of all apps you don't need much state. They don't have deeply nested components so you can simply store the state in your root components (Screen/Page) via setState and pass everything down via props.
If you end up with deeply nested probs, use "unstated", it adds a bit better usability to the context API and lets you avoid the props-drilling problem. You basically get something like the "connect" from Redux, without the rest Redux would require.
If you somehow end up with an app that fits in the 1% who need fully predictable control over their global state, go for Redux.
React is the simplest framework I've ever seen, sadly Redux and co made it much more complex than needed to be, which drove many people away from it.
That's what I hear from every Redux proponent.
And I guess if you put in the time and became a Redux pro, there is no reason to switch.
But if you're starting out or have to work with non-pros, you're probably better served with unstated.
If you're a single dev who knows Redux or working in a project with Redux pros, I'd say go for it, you invested your time into it, why not use it.
This is actually my problem with redux - developers tend to put everything in the store.
I read things like: <Subscribe to={[CounterContainer]}>
Why are [ ] needed? And what do [ ] mean here? I thought { } were enough for evaluating code.
The `{ }` that wrap it are just part of the syntax of passing props. If you wanted to pass an object literal to a prop, you'd have to double-up the curly braces:
<div style={{ color: 'white' }} />
// both of these are fine:
<div id='foo' />
<div id={'foo'} /> <Subscribe to={[CounterContainer, SomeOtherContainer]}>
{(counter, someOther) => ()}
</Subscribe>If you base it on some external entity, you need to trigger a render manually.
These state libraries usually let you wrap your component in another component, that passes the state down as props, so when the state changes, new props are passed down and your component automatically renders with the new state.
I'm not saying this works for all apps, but I got pretty far with it.
If you're making a todo app, yeah sure, no redux. Creating an app without conventions to manage state? good luck making all of those decisions.
Up until recently, the maintainers of Redux have neglected to meaningfully rein in the hype. If your react app is "complex" and "depending on your usecase"[1], redux must be used. Which is why the very first tutorial in its documentation is a... TODO app. A basic concept deliberately over-engineered to fit a framework that isn't suppose to handle "simple" apps. What?
Developer under great social pressure must resolve this glaring dissonance themselves. Developers who may feel more insecure in their knowledge of front-end engineering than they would like to admit. [2]
Well, for these developers, it can't be that they're not be "smart" enough. On the contrary, with some mental gymnastics [3], this "smart" framework will solve their "smart" problems, and then they will be "smart". The unspoken corollary is, of course, that anyone who disagrees with the "smart" framework" is not "smart".
What begins as misleading by the maintainers creates poison in the enterprise. Suddenly, this popular framework becomes the norm, as team after team is forced to conform, applying this "smart" framework to domains that aren't explicitly forbidden by the docs, to consistently, poor results.
Thus the driving force behind Redux became the deep, deep denial of insecure engineers, imprisoned by their own monoliths. Finally, there's a backlash. Without strong-technical-merits or clear-headed communication by the contributors, Redux will likely deflate and be limited to legacy code and the few cases it supports tremendously well.
Essentially, for those who've been around the block, Redux is to React what AngularJS 1.0 was to JS frameworks. A shame that we had to suffer through this cycle again.
[1] Dev-speak for "If you know what's good for you"
[2] As said recently, "Most Developers would not hire themselves"
[3] The test for this is if the Redux TODO app makes sense to them.
I wrote this a year and a half ago: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Controlling the hype bubble would have meant rewriting the introduction of the docs, for example, replacing the TODO app with something actually intelligible. This drastic act would also have required buy-in from all the maintainers-- one of whom just posted an article protesting too much the decline of the framework in question.
From an outside's perspective, the damage control seems too little, too late.
As for the examples: the "TodoMVC" example was already well-established as a common way to showcase JS MVC frameworks by the time Redux came out, so it was a natural choice for the Redux tutorial. We do have several additional examples in the repo, and the "Advanced" docs section builds out a small Reddit client to demonstrate working with async logic.
Docs writing is _always_ hard. As Dan originally said when he was writing the docs [0]:
> So hard to write the new docs. Many different audiences to cater to. Should make sense to: Flux beginners, FP people, FP people who don't get Flux, Flux people who don't get FP, normal JS people too. Flux people: “is this proper Flux?” FP people: “is this that weird thing called Flux?” Normal people: “why not Backbone”.
Now, I'd say that the JS landscape has definitely changed since the docs were written in 2015, and I'm open to ideas for revamping them. But, you also need to illustrate the basic concepts and workflow of a tool without getting bogged down in irrelevant details.
Finally... what "domains should be forbidden by the docs"? I've talked to people who have put just a few bits of data into Redux, and others who have opted to put literally _everything_ in their app into the Redux store. Both are viable approaches. Why (and how) should we say "no, don't do X with Redux" that way?
If you have specific concerns about the docs, or the way Redux is described and taught, _please_ don't just complain! I'm _always_ open to suggestions for improving the docs and the Redux ecosystem. Please give us some positive contributions and help us make things better for everyone.
[0] https://twitter.com/dan_abramov/status/622567874796855296
Well, the headline you chose will hearten the faithful and give pause to everyone else. That plus the defensive tone of the article, sabotages the very framework you're championing. In my opinion, you should have have ran it all by Dan or other maintainers before publishing.
More worryingly is your response to the critiques of this thread. If my concerns were so wrongheaded and just so darn disagreeable, shouldn't you have simply ignored them? Or wait and see if they were validated by others?
Unless, if course, I'm giving voice to a suppressed thought, something that is already known but refuses to be known. Maybe that would explain the lashing out. I don't know.
I just don't have the same emotional investment in Redux. All I'm seeing the same worn-out hype-cycle playing again and again.
I found the response to be quite reasonable, and certainly not worrying.
Why would it be a good idea to ignore people that disagree with you? It seems like it would be better to provide rational counter arguments, in the hopes of starting a useful discussion.
I have used Redux on a few projects, largely due to the hype (I.e., good recommendations from others in the community) surrounding it. Without intending to I ran into several discussions on SO and Github where Dan explained why people may not need redux. I think this is a very nice thing, and I think it is unfair to blame Dan or other developers for not reining in the hype more.
I do agree that the title of the article is a bit alarmist and perhaps counter productive.
A good example of how to ignore concerns would be comparing Dan's responses here with that of Acemarke's. Dan's is to-the-point and confident, whereas Acemarke's is... markedly less so.
Really, the issue here is not how one developer communicates but how they communicate as a team. It's obvious that this self-damaging article wasn't formally approved by every Redux stakeholder-- but I also recognize that no one on the team expected for this to happen.
I've found a nice niche answering people's questions about React and Redux. I spend a lot of time in the Reactiflux chat channels, as well as a variety of other platforms (Reddit, HN, SO, Twitter, etc). I see questions, my natural impulse is to try to respond and answer them.
Dan Abramov and Andrew Clark created Redux, but now both work at Facebook and are no longer active maintainers. Dan handed over the keys to Tim Dorr and myself. While we don't have any formal division of labor, the typical pattern is that Tim takes care of most of the actual code tasks (merging fixes and publishing releases), and I handle most of the docs stuff and interact with people using it.
None of us have any particular veto over what the others do, and I don't see why I should have "run my post by them" before publishing it.
Yes, the article's tone was defensive, because I've been seeing the same questions, concerns, and FUD get tossed around. So, I was trying to answer those questions and clarify the situation. Most of the feedback I've gotten on the post has been quite positive, along the lines of "Thanks for helping clear that up!".
Maybe responding to you was a bad idea. I dunno. I just get frustrated when I see people complain about things without actually trying to make them better. As my mom told me dozens of times growing up: "You've stated the problem, now state the solution".
So, I'm not "lashing out", and I'm not saying your concerns are "wrongheaded". I'm trying to understand what the actual specifics are that you're concerned about, and find out how we can make things better going forward.
1.) There is an immutable data store with action-driven changelog, just like Redux.
2.) The immutability of the data store is baked in and enforced. The necessity to provide changes to the data store within an action is baked in and enforced.
3.) Having actions baked in as methods rather than having to create "action creators which in turn dispatch actions" is a nice reduction in boilerplate.
4.) Being able to add action listeners AND state listeners are baked in, and can be done at any level of the state's depth. To watch state changes in redux, for global changes not related to a particular component, I had to write: https://github.com/ralusek/redux-store-watch
5.) Mobx's observers on react render methods makes the renders far more efficient than what could be achieved with react-redux easily, without really ensuring that the props being passed in are as granular as necessary or shouldComponentUpdate is correctly identifying state changes. In mobx, the most granular access of the lowest level state can be detected within a render method, and only when that very specific value is replaced is the component rendered.
6.) Computed values on mobx-state-tree are baked in without the need for something like reselect
I like Redux, I enjoy working on projects that use it, but I think that I think I'd have to admit that I prefer mobx-state-tree.
I really liked using MST when I spent a few days fiddling with it. However, I really don't want to get trapped with perf bottlenecks I can't easily fix. Whether I'd actually run into trouble - I have no idea, but vanilla MobX is excellent enough that I'm happy sticking with it. I'd love to use MST more though.
MobX observables+computeds are such a useful and powerful tool, I'd struggle to create non-trivial UIs without them.
How is your experience with testing MST? Is it as easy as with redux?
It's a shame there's no reference in the README. Makes it seem like they don't take testability seriously, which for me is a major plus point of Redux.
For new project I also prefer mobx-state-tree over redux.
In regards to #5 redux there's a pattern to use selectors (which can be memoized with reselect), which means that whether components update is a simple shallow === comparison on their data props, and also a handy abstraction for getting data out of a potentially deeply tree and applying transforms to it.
#6 looks interesting, though.
I kept pointing out to members of the team that even Dan Abramov's post about maybe not needing Redux... but it fell on def ears like I didn't "GET" redux.
I totally understand the enticing time-travel feature, but I think too many people jumped on the ship before it was ready for the use-cases different folks had in mind.
So state management libraries are not solving a unsolvable problem, they are here so that we can write cleaner, more efficient code that potentially can become more performant. At least that's what happened in my case.
I think the bigger reason that a global state management system becomes necessary is when the shape of your component tree doesn't closely match the shape of your state tree, because that means state (and callbacks) need to be passed down through components that don't care at all about that state simply because one of their distant descendant components does care about it.
A challenge I had recently was a location form field, where the user is offered autocompletions as they type. The autocompletion state is specific to the component; every field needs its own unique state. So to represent this with Redux, the component has to generate a "state ID" (basically just "new Object()", as I recall) that serves a unique identifier that it can request lookups under. The autocomplete() action then has to take a state ID as a parameter, and associate all lookup state with that ID. Internally, I implemented this as a layer on top of the autocomplete engine, so that the underlying layer didn't know about the ID. Even so, it wasn't beautiful. And of course it was susceptible to leaks -- it was necessary to "unregister" the state ID on unmount. It was unpleasant enough that I considered not using Redux, but I've done that before, and I really wanted the whole state transition machinery.
Has anyone created a solution for this, I wonder? It's possible that a new Redux store per field would have solved everything. But can you connect a component to multiple stores? Some components need to have instance data and access the global store (e.g. current logged in user).
In general the solution would be some kind of class with .acquire and .release methods to create/recycle objects as needed. It comes up often enough that I'm a little surprised there isn't at least one or more popular libraries for it.
In my own app, I store a variety of data in the Redux store: data fetched from the server, UI state like modals/context menus/tabs, app control state like "current selected item", etc. Certainly not all UI state _needs_ to go into Redux, but there's nothing wrong with storing UI state in Redux. Totally depends on where and how it's needed.
If the state is likely to be a common concern, or referenced in another component, them redux it up. If the rest of the app doesn't know/care then scope that state.
If you're using Provider or subscribe() you're going to end up hammering lifecycle methods unnecessarily in relatively trivial UI changes. Just seems unnecessary.
> 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.
> Some common rules of thumb for determining what kind of data should be put into Redux:
> - Do other parts of the application care about this data?
> - Do you need to be able to create further derived data based on this original data?
> - Is the same data being used to drive multiple components?
> - Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
> - Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
As a super simple example, if you had a list of continents, and each continent could be expanded (to list every country inside of it) or collapsed, your Redux state might look like:
{
'continents': [
'Asia': {
'collapsed': false,
'countries': [
'Mongolia',
'Japan',
// ...
],
},
'North American': {
'collapsed': true,
'countries': [
'Canada',
'Mexico',
// ...
],
},
],
}
In what case would you need to generate a random ID per component simply to "remember" where the data for each component is located in Redux?
Yes, generally something like expanding an accordion component can just sit in the local component state, as long as the collapsed state doesn’t need to affect or be affected by other app state.
{
'<randomId>':
{
Asia:
{
collapsed: true
}
}
}
Probably the ContinentsList component would somehow look like this:
<ContinentsList
continents={<continents data>}
renderItem={({ collapse, isCollapsed, continent }) => {
return <ContinentItem onCollapseClick={collapse} isCollapsed={isCollapsed} continent={continent} />
}}
/>https://github.com/markerikson/redux-ecosystem-links/blob/ma...
That said, did the component really _need_ the autocomplete state to be stored in Redux in the first place?
In this case, it was a component that not only autocompletes a location, but also offered to geolocate the user (via the browser's geolocation API) and supported a few other features that meant it was several competing concerns wrapped into a single UI. Those can get hairy if you don't do a Redux-type state machine.
Also, as a side note, you may want to check out recompose’s withReducer HOC, which is effectively a way to use the Redux action+reducer flow to manage the state of a single component (without the separate store, the context stuff, etc. that Redux provides):
https://github.com/acdlite/recompose/blob/master/docs/API.md...
In case you’re interested, ReasonReact also provides a reducer component as the only way to have a stateful component. The pain of “boilerplate” basically goes away in a typed language:
https://github.com/reasonml/reason-react/blob/master/docs/st...
Creating solutions to problem we invent.
There needs to be a line between UI state and application state.
I've had similar issues with MVVM in WPF. Do you really need a observable property for "UserClickedThisSoMakeButtonGreenAndShiftThisPanelOverALittleBit" in your view model? I'm exaggerating of course, but there is a line. There is nothing wrong with UI specific code in your component.cs code-behind, same story for react.
I love Redux, I think it deserves the title of genius, but you often do not need it.
I've built a couple of apps with redux and always wished it was closer to clojurescript's reframe in terms of minimal boilerplate. Rematch does exactly what I need.
You should be able to refactor Rematch to Redux without much issue if necessary.
So, uh... Redux co-maintainer and author of that post here. Happy to answer questions and point people at possible solutions :)
I haven't had time to try it myself, but it looks conceptually interesting.
I contributed some of the initial documentation [1] for testing middleware back in the day.
Wondering if there are any areas in particular you'd be looking for contributions? I use redux every day and would like to contribute back some (if it would be helpful).
Beyond that... oh, boy. I'd love help maintaining my React/Redux links list [1]. I've been really busy the last few months and have fallen behind on adding new links, and it could also use some maintenance attention to look at the existing links and figure out which ones are outdated and not really useful any more.
The "starter kit" lib I threw together [2] could use more design work and ideas to figure out what other "batteries included" type things we would want to include out of the box as an official Redux-branded library to solve some of people's common pain points.
React-Redux has some open PRs related to React 16.3 [3]. It's starting to look like we need to put together a bigger v6.0 major version release with some combined changes, and it would be good to get more eyes on the situation to figure out what's needed. There's also an open PR for adding an "object shorthand" for selectors with `mapState` that's been lying around for a while waiting for someone to add some tests so that we can say we're happy with how it works and merge it.
[0] https://github.com/reactjs/redux/issues?q=is%3Aissue+is%3Aop...
[1] https://github.com/markerikson/react-redux-links
[2] https://github.com/markerikson/redux-starter-kit
[3] https://github.com/reactjs/react-redux/pulls?q=is%3Apr+is%3A...
Like let's say you decided to use GraphQL and Context API you would still need Redux in these cases?
> Yes, the new context API is going to be great for passing down data to deeply nested components - that's exactly what it was designed for. If you're only using Redux to avoid passing down props, context could replace Redux - but then you probably didn't need Redux in the first place. Context also doesn't give you anything like the Redux DevTools, the ability to trace your state updates, middleware to add centralized application logic, and other powerful capabilities that Redux enables.
> I'd agree that data fetching via GraphQL, and especially with Apollo, will likely reduce or eliminate your data-fetching related Redux code. And again, if that's all you were using Redux for, you probably wouldn't need Redux after moving all the data-fetching handling into Apollo. ... But, as with context, I'd say there's definitely use cases where Redux is going to work better than GraphQL + Apollo, and possibly without requiring as much buy-in throughout your architecture.
Dan Abramov's "You Might Not Need Redux" post [0], which I linked a couple times in there, lists a variety of use cases where Redux absolutely shines.
[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Though it's a very new library (Dec 2017) so it has a long way to catch up in terms of tooling and support.
I just happened to write an article on apollo-link-state for those who are curious about how it's used.
https://hackernoon.com/setting-up-apollo-link-state-for-mult...
Given that "boilerplate" is a typical complaint about Redux (which can itself be handled with whatever abstractions you want to put in place), I'm not seeing the appeal here. Is it just a case of "we're already using GraphQL, so GraphQL all the things" ? (Note that the article itself doesn't use the word "boilerplate", I'm just pointing at that as a reason I've seen people throw out for wanting to move to link-state.)
I actually think mobx-state-tree is my favorite of them all, but I shy away from it due to its performance issues. When they solve that, I will likely adopt mobx-state-tree quite often.
Like most people have mentioned, it would be nice if we could some how reduce the amount of boiler plate needed, or perhaps a pattern will emerge that will help manage it better.
For me, the true benefits of redux became clear when I learned how to properly normalize the shape of the data (https://redux.js.org/recipes/structuring-reducers/normalizin...) in the store. Unfortunately to do this efficiently it requires more boilerplate and dependencies like normalizr.
At this point in the evolution of SPA architecture, it definitely feels like something is wrong because of the way we manage our data across the stack. We normalize our data to our RDS, de-normalize it in our API, then re-normalize it in our application interface.
Interesting and exciting to watch the evolution take place though.
I personally am a fan of Redux-ORM [0] as a tool for handling normalized state in the store (and I show how to use it in my "Practical Redux" tutorial series [1]), but there's quite a few other options as well.
My biggest frustration with the word "boilerplate" is that it not only gets thrown around a lot, it means different things to different people. Which _specific_ aspects concern you? What pain points have you experienced?
I agree that the term boilerplate has been diluted lately. I also have to admit that I use it in this instance because it seems to have become the adopted term for what essentially means "takes a lot of code no matter the complexity". So to clarify, when working with Redux, it _feels_ like it takes a lot of code to handle data in states, no matter the complexity.
More likely, redux is intended for larger projects with complex state management. So yeah, there is a lot of code to setup even basic data within a state, but the benefits probably start paying dividends as the state becomes more complex. With that said, I doubt anyone working with extremely complex states is complaining about too much "boilerplate".
I was considering contributing to Redux but when I checked github it didn't seem like there was too much that needed help. Let me know if that's not the case. I love the project and would enjoy contributing.
Thanks again for your hard work!
We experimented with simply using large stateful react components instead of redux for certain areas of the app, and our reusability improved dramatically.
Any thoughts on how this is tackled by some hardcore redux users?
The factories can take config for which action types to handle, etc.
This way we can easily test and reuse the actual "hard logic" for those parts, don't need to worry about trying to reuse the actual Redux stuff, and can add/modify the input or result from the helper functions slightly if needed per app.
Yes, it's more boilerplate, but it's served us well.
[1] https://hackernoon.com/transmission-tx-a-flux-alternative-fe...
What this doesn't really get you compared to Redux is a consistent, serially updated, immutable state tree, and every state ("engine") becomes a somewhat ad-hoc event manager. Redux does get the concepts right, in my opinion. Your system doesn't really solve anything better, as far as I can see; it just calls actions "events" and splits the state tree into "engines".
Redux is too simplistic, though. It does nothing to solve some of the actual hard problems people face in an MVC system, such as async loading (which comes with a bunch of can of worms: Retries, error handling, idempotency, progress events, cancellation, etc.). I don't know of anything that does this well on top of Redux.
The fact that the event model and state tree are both global and shared means Redux makes it hard to encapsulate stuff, too. Encapsulation is less of any issue if there is a single instance of everything; if you have a single user controlling the page, then it makes sense that there's just one global user, and one global state for each of the user's things. But often you have multiple instances of state, and there are no tools to help you coordinate events and actions. For example, say you have a page that wants to display several charts in different boxes, and users can add new charts to the page. Every chart component "points" to which dataset it wants to render, and each dataset is a separate node in the state tree identified by ID. The actions and events then all have to refer to this dataset ID; you effectively get a little "routing layer" for actions where each action needs to look up the state by dataset ID to get the actual thing to operate on. I've not found any reusable tools to handle this.
One reason Redux doesn't scale well is just the amount of boilerplate and repetition. You can solve this with some smart meta programming, especially in TypeScript. But it's not entirely a solved problem.
For the charts example, I would just instantiate a new redux store with its own state. The reducer can be reused between chart instances. Then just dispatch other action(s) to your main redux store if you need chart state in your main store.
In the end, such actions tend to be extremely similar. I tend to have groups of related actions that all such actions need. LOAD_FOO_REQUEST, LOAD_FOO_SUCCESS, LOAD_FOO_FAILURE, etc. A middleware can regex-match on the action name and count how many are in flight to render load progress. Similarly, errors can be caught that way.
Idempotency is a bit harder. Often a load action has several dependencies (e.g. you want to load data based on a query and a limit) that need to be encoded in something that represents that request so that if another request is issued, it can be ignored if it's identical. This ends up being boilerplate, too. Maybe one could write a generic middleware that tracked what the in-progress request is and skipped duplicate actions.
Cancelation is harder. I've never done this with Redux, as the biggest blocker is that promises can't be canceled. Last I checked, WhatWG's fetch API doesn't either.
Retrying, ugh. At least this one isn't too hard to make generic, since any Redux action can, in principle, be retried. In a recent project, I rendered a notification box with a retry button if an error event embedded a retry function, which in turn just resubmitted the action. But it wasn't a very general-purpose solution.
My own apps have been fairly simple in that regard, so while I've seen a bunch of libraries to handle data fetching in various capacities, it's not an area I've had to deal with myself. So, I'm not sure what kind of "other framework handles it this way" comparisons exist.
It makes pretty much all the things you listed (cancellation, ignoring identical requests, retry) far, FAR easier to reason about, test, and implement.
+1. Redux is a great library, but I think its a little hard to grasp at first, and it doesn't yet provide a proper framework for solving problems in a clear manner. It wasn't until a year + of using Redux and reading quite a bit code until I developed a mental framework for how to approach certain components in Redux (and whether to use Redux at all, vs. setState).
Your "chart grid" example is something that I went through 3 iterations of until developing the "right" higher order component (which if you squint, could be confused for meta programming) for our use case. As a developer what you want is the right abstraction that prevents your "dataset ID" from leaking everywhere (ideally only your HoC should care about your "dataset ID", much the "redux-form" API you really don't need to interact with the "form" name once you've defined it). Once you have that, then you hopefully you have a reusable API that can scale or at least small enough to live in one developer's head without them having to wrestle with the entire application.
I'm not sure how you fix it. Most of the patterns I discovered already exist under many different Medium articles.
It didn't take long as Redux got popular for the discussion to turn into "how to avoid boilerplate", "how to make things more SOLID" (OOP principles in Redux, lol!), and "you should use setState most of the time".
That was the silent nail in the coffin. Very little progress was made in Redux patterns ever since that would not better be solved using other tools (MobX, Apollo, 16.3 context, whatever). Which is a shame: "Old school Redux" is amazing. There's a reason initially people flocked to it and said "OMG use it all the time for everything!". It's really that good. "Modern" Redux is a fragmented overcomplicated useless mess with a community that missed the point. Now get off my lawn, I guess.
I don't recall ever seeing comments about Redux and "SOLID". The commentary about "boilerplate" and use of `setState` has been in response to people's concerns. It's a shame that's where we've had to focus our time and attention in messaging.
Can you clarify what you mean in the last paragraph? What specific concerns are you thinking of?
I know you've talked in the past about the way your teams are using Redux. I'd love to see a couple posts that give some details on that.
You know I'm always happy to chat about ways we can improve the docs and help the community. _Please_ ping me sometime - I'd love to hear whatever suggestions you have. You know where to find me :)
In the early days, the average Redux user was someone who had been burnt by Backbone or Angular 1.x state management, was excited about the solution Redux provided, was curious about Redux's FP characteristic or more rarely might even have been an FP zealot. There was a lot of chat around that area, how to handle specific problems from that angle.
As time went on and it became very popular, the "community" (I use the term loosely, as there's no single entity representing "the community") grew, and the typical Redux user was very much the same as the average JS dev. Usually a OO background or familiar with more classical languages and patterns. Just want to get shit done and doesn't care about the Redux pattern's unique characteristic. Uses Redux because everyone else is, not because they see value in the event sourcing-like decoupling.
A lot of things come from that. Like already mentioned, the focus came a lot more to "how to I reduce boilerplate", "waah I dont like passing props down", "code reuse!", "how do I make things look like my familiar OOP patterns".
That's all valuable and I don't want to downplay it (there's only so much nuance I can put in a stack overflow post), but a lot of this is available in other tools and other frameworks. MobX and state trees are pretty nice. I can just use that.
Redux itself has a few things others have not:
1- Popularity, but that's a completely artificial thing. Any other pattern could become popular. It does mean it has the most complete ecosystem, but we can replicate anything elsewhere if we need to.
2- FP-ish, Elm-esque, event sourcing-like characteristics. Nothing even remotely mainstream outside of other languages (Elm, PureScript, ReasonML) have this. But there's very little effort these days in tapping into it.
For example, the "connect all the things everywhere!" makes the predictable dataflow aspect of Redux a lot more fuzzy. In large apps we don't have much choice though: there are major perf issues if you don't connect deep enough. It's a problem that can be solved, but I've never seen it solved. Redux being used as a glorified context container to save on typing can be solved with better design patterns. There's very little research done in that area anymore, so it's here to stay. Side effects being handled by thunks/epics/sagas works fine, but we could do better. Back then there was a LOT of research and attempts done in that area (remember redux-loop? I miss redux-loop. The syntax sucked. Can't we do better, several years later in a world of generators, async/await and observables? I bet we can!).
The obsession in making Redux, a functional event sourcing like-thing into something palatable to the average developer is just trying to fit a square peg in a round hole. There's nothing unique about Redux to make it appeal to those use cases and sub community. What if we looked at Redux, and instead of only focusing on that, we pushed what makes it unique to it's limits?
After all, back when the first Redux demo and timetravel debugging was shown, the world revolved around OOP JavaScript. It pushed people out of their comfort zone a little.
I'd show you the code we write here, but with hundreds of devs, they learn from the same place everyone else do. As we've grown, all the patterns (and anti-patterns) you see everywhere are also present in our own code, and we fight these battles internally too.
I'd be more than happy to chat more, but to me, that was always a battle that was lost years ago, when discussions devolved into "ivory tower vs pragmatism" (remember http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho... ?)
This really isn't a form of discussion I feel is productive. To join force within a problem space and solve problems in that space, you need several people aligned on a common goal. The problem space and common goal I'm interested in isn't "How do we make Redux work for everyone", it's "given an assumption that certain FP patterns, event sourcing, global state and event logs are high value patterns, how do we solve real world problem with them". I'm not sure this is possible anyore without alienating tens of thousands of frontend developers, without starting something else from scratch.
Edit: phew I hit enter and didn't even realize how much I wrote.
So TL;DR. You and the rest of the team are doing a fine job, but as with all things that are popular, there are "sub communities", and its impossible to make everyone happy. My pie in the sky dream is for people that don't like Redux to use something else, and for Redux to focus on its strength instead of always trying to fight its (by design) weaknesses.
I've already spent more time in this thread than I really should have, and I'm also sorta slightly burnt-out after spending the last few weeks putting together my first Redux workshop. My immediate priorities for the near future are trying to consolidate the PRs and issues we have for updating React-Redux to work with React 16.3+, and pushing forward on the "redux-starter-kit" package I put together.
That said, yeah, I _hate_ that we've had to spend so much time "defending" Redux rather than figuring out niftier things to do with it. I've seen a lot of interesting experiments in the community, but haven't had time to really go off and investigate or play with them further. (I don't even have enough time for all the blog posts I want to write :( )
At a minimum, Redux has been hugely instrumental in changing the minimum bar for debuggability and state tracing, but yes, I'd love to figure out ways to push the envelope somehow.
Yup, everything popular goes through that. I like the MMORPG analogy. New MMO comes out, is popular, shiny, everyone's into it. Then the WoW communities move to it and request...DEMAND that it be changed to match their expectations. Game devs try super hard to catter to the WoW communities and fail. WoW players all quit. Game developers then either give up, or focus on the core player base that actually liked the game as designed originally. At that point the game either thrives and becomes the best it's ever been (with a much smaller user base), or it dies.
Ember is one of those I think: I don't like it, but everyone who hates Ember stopped using it long ago, and it's serving people who like it quite well. It's not shiny or sexy, but for them, it works very well.
> The obsession in making Redux, a functional event sourcing like-thing into something palatable to the average developer is just trying to fit a square peg in a round hole. There's nothing unique about Redux to make it appeal to those use cases and sub community. What if we looked at Redux, and instead of only focusing on that, we pushed what makes it unique to it's limits?
You're right: handling async events did become a headache with Redux and we were forced to wrap it with our own framework (we opted against redux-saga). You're also right about the boilerplate. With Redux, the code became a lot less confusing but a lot more tedious...
One you do write this framework in Redux, however, you can reuse it and the amount of unnecessary boilerplate goes to near zero in my experience.
We just need a de facto open source framework built on top of Redux for people who haven't worked with it extensively to build with.
A few months ago I had a little bit of free time, and threw together a tiny "starter kit" library [1] that is intended to simplify a couple of the common pain points (basic store config, and writing reducers with immutable updates). I haven't had time to push it further, but long-term it's likely to become an official Redux-branded "use this to get started" addon.
I'm very open to further ideas and suggestions around this topic.
From working with people who haven't used Redux before - these seem to be common things people new to Redux want to do but find difficult to get started. (The boilerplate around making actions and switch statements, etc. seems a bit secondary in my opinion)
However, I realize the "proper" way to do the things I listed above is inherently pretty opinionated, so I totally understand why the Redux library itself has avoided including these things (it's much more flexible as-is; and probably why it's been so stable and stood the test of time).
There are quite a few existing libs for doing data fetching and collection management ( https://github.com/markerikson/redux-ecosystem-links/blob/ma... ), ranging from simple normalized reducers to complex "auto fetch from a REST or JSON-API and provide full CRUD support" libs.
I simply don't understand the complaints about switch statements myself, but it keeps coming up, so it seemed like a simple enough starting point for a "starter kit" library like this.
I think redux just became hyped because of its "time travel debugging" which is just pure functions returning some stored values.
But the conectps in redux IMO are worth learning, made me think about my own code different. More pure functions, less sideeffects...
This lead me to the creation of DotStore (https://github.com/invrs/dot-store#readme), along with extensions to use it with React [1] and the filesystem [2].
"Dot prop" strings have proved to be an elegant solution to detect which props changed on the store. Usually this means doing a regex match in `shouldComponentUpdate`. We almost never use React's state anymore.
[1]: https://github.com/invrs/dot-store/tree/master/packages/dot-...
[2]: https://github.com/invrs/dot-store/tree/master/packages/dot-...
This line from the article got me though.
"plus all of its usage with other JS frameworks like Angular, Ember, and Vue"
Are people actually using Redux with Vue? Everyone I know is using Vuex for state management for Vue.
Now, Dan and Andrew have suggested that in order to have React-Redux work properly with the upcoming async React rendering, we should possibly consider reimplementing the Redux store logic to use React component state as the basis. In other words, you'd probably do something like `import {createStore} from "react-redux"`. I'm not keen on that idea myself, and am hopeful we can find an approach that will allow use of a separate standard Redux store and still get the benefits of async React rendering down the road.
That said, I presume the majority of Vue users are using VueX.
Eventually though some containers started to have their own state, derived from props.
Ultimately I was left with the feeling that I wasnt really getting the full benefits of redux (time traveling, centralized middleware, etc) without moving all state in my app to Redux.
I think this is how teams get trapped by Redux - the pursuit of having nice dev accordances like time traveling leads them to adopt Redux everywhere and just by Redux’s nature (immutability, declarative actions) it ends up complicating things way too much.
I think the article I’m most grateful for is Dan’s article on container vs presentational components. Sticking to that philosophy let me adopt Redux and try it out but still have the majority of my app in dumb, non-Redux presentational components. So now it’s easier to remove Redux if I need to.
I've certainly talked to people who literally put every single value in their app into Redux (often in conjunction with _only_ using functional components). I can understand why they might choose that approach, but to me that's over-opinionated. Most of my app-type data does go into Redux, but it's absolutely fine to use React local component state for whatever doesn't need to be shared.
Time travel is nice, but it is not worth putting everything into your Redux store.
FTA: “If you're only using Redux to avoid passing down props, context could replace Redux - but then you probably didn't need Redux in the first place”
I use Redux sort of like Core Data (in iOS world) - I just use it mostly to store external data since it’s valuable to track the modifications to and morph (via reselect) specifically that kind of data.
If I ever have other local state it just sits in components. But most of the time components have no state at all.
My point was mostly that you shouldn't be afraid to let state live in Components and that should be your first instinct even if you are already using Redux for any one of its benefits.
There are other reasons besides prop-drilling to offload state into the store, but don't do it if your only reason is "I want to make debugging marginally easier".
This pattern of some _thing_ becomes popular; everybody says to use _thing_; people use _thing_ where it's a bad fit; tsunami of people says _thing_ is broken. _thing_ keeps living.
Examples: redux, react, S3, EC2, AWS lambda, heroku, docker, angular, ruby-on-rail, rust, golang, well every _thing_ :)
It shows you redux as it is using plain javascript, without involving react, which gave me a clear idea of what redux actually is.
For a very simple example:
import { UserIdConsumer } from '@/contexts'
const ThisComponent = () => (
<div>
User ID: <UserIdConsumer>{value => value}</UserIdConsumer>
</div>
)
export default ThisComponent const UserIdConsumer props => <Fragment>props.children(theValueYouWantAvailable)</Fragment>This:
<Component prop="value" />
React.createElement(Component, {prop: "value"}, null);
h(Component, {prop: "value"}, null)
<?php
if (condition) {
?>
<div>whatever</div>
<?php
}
?>
if (isLoggedIn) {
return <UserGreeting />;
}
This is fine:
<?php
if (condition) {
?>
<div>whatever</div>
<?php
{
?>
if (isLoggedIn) {
return <UserGreeting />;
{ function
ThemedButton(props) {
return (
<ThemeContext.Consumer>
{theme => (
<button
{...props}
style=.
{{backgroundColor:
theme.background}}
/>
)}
</ThemeContext.Consumer>
);
}
Moreover, JSX components are plain old Javascript functions and classes. You write plain old code that follows normal rules if the language when you deal with them.
JSX DSL is there for convenience because it's, well, extremely convenient.
There are feeble attempts elsewhere to equate JSX with writing HTML inside PHP tags which fall apart the moment you give JSX more than a give-second cursory glance.
JSX is a paper-thin DSL on top of Javascript. JSX components are regular Javascript functions and classes. You work with them the same way you work with any function it class in JS. Unlike PHP where it was actual HTML interspersed with PHP code.
Whether I type `return (<button>foo</button)` in react or echo '<button>foo</button>' in php, it's the same thing from my point of view as an application builder.
Such as? This is the point in dispute, so you need to actually make specific arguments if you think they apply.