It basically tries to enforces a few old ideas, pure functions, message passing and immutability, with no help from the language, which results in verbose and ugly code.
`a.b = c` becomes `Object.assign({}, a, { b = c })`
and
`object.method(data)` becomes `store.dispatch({type: METHOD, data})` with the implementation code of the "object" being a huge "switch" statement.
If you want immutability, pure functions and message passing, then why not use a language that is build around them and make your life easier? Clojurescript maybe?
Also having a single store for all your data, definitely doesn't help with speed as a single event suddenly becomes an O(LogN) operation in the best case.
- It has helped many developers organize their "write logic" and state management, and made it easier to test that code
- Time travel debugging is a fantastic tool for understanding what happens in your application
- One of my favorite quotes: "Redux is a generic framework that provides a balance of just enough structure and just enough flexibility. As such, it provides a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware."
- And it doesn't hurt that Dan Abramov is a well-known figure in the React community, and an incredibly helpful and friendly person too.
No, Javascript doesn't have immutability built-in (sadly), but that doesn't mean you should totally give up on applying those principles in Javascript code. There's WAY more developers writing JS than Clojurescript, and those devs can still make use of tools like Redux in their applications. Besides, there's a variety of approaches for handling data immutably, whether it be `Object.assign`, the Stage 3 object spread operator, Immutable.js, or the many immutable update utility libraries out there.
Your comment about speed doesn't make sense. A few function calls and switch statements will execute quickly overall, and perf benchmarks will show that your reducer logic is almost never going to be the bottleneck in a Redux application.
Dan Abramov is one of the most actively helpful open source authors I've even encountered. He debugs basically every Github issue that gets opened against his libraries.
I think immutability is actually the crux of the problem here. Why is it used? So the UI knows when to update... Redux applies layers of complexity just to know when ur UI is going to update (efficiently)... Thats a scaling issue! So ur store cant scale to large data-sets because of immtability, and your app cant properly model ur ___domain, because it needs to be flat to support updates.
That shouldnt be an afterthought for a state management library that uses the principles of event sourcing to create a state tree.
I think its these two ideas clashing that causes the verbose code, the community complaints, and slow code as described in the post. Why should i need to mutate references?
IMO it would be alot more palatable if redux persisted events, not the store. And was opined about the event structure, instead of everything else. ie. Use inheritance/events to then control UI updates.
ie. NOT Comment_Added { postId:.., comment: .. }
rather Comment_Added : PostDomainEvent {comment: ..}
now on the page where i am viewing a current_post, i can simply connect to my state, and re-render whenever i see a PostDomainEvent of id == current_post_Id. I can also buffer re-renders based on the amount of postDomainEvents i see per second.
This way, as someone using the library, my events are my focus, not my store. I dont need to remember to mutate this, or do that. I get precise control, and anyone can implement the store in any technology they want. sure i need an "unreduce" to get time-travel debugging, but thats not a trade-off thats forced on ppl who dont need it.
For what it's worth, immutability matters for more than _just_ having React-Redux properly update. It also matters for time-travel debugging, and to some extent for proper reducer testing.
I'd very much disagree with the phrases "can't scale to large data-sets because of immutability", and "app can't properly model your ___domain". If you follow the suggested pattern of normalizing your state like a database [0], then modeling relationships between data types is entirely feasible, AND you can update the individual items efficiently (and if you don't want to write that code manually, there's a ton of addon libraries to help you manage those relationships [1] [2] [3]). At that point, the only real limit to how much data you load is browser memory, same as any other client-side framework.
Exactly, lets say my data structure stretches the clients memory, adding immutability ontop of it doesnt cut the mustard because its not baked into the language. Thats my point, "redux" doesnt scale. "Time-travel debugging" doesnt scale either (as implemented by popular middleware), because serialising my state on every transition is 5MB + 5.0001MB + 5.00012MB etc etc operation. Immutability is great for parallel applications, in browser JS is not one such app. Not yet anyway.
Additionally, i question the logic of "normalising" my data structure for the client --> just so i can update my UI efficiently. Whats the point of using universal JS?
What i am saying is redux NEEDS immutability to deliver on its promise "out of the box" - lets face is, sure u can extend redux to mute this requirement, but then whats the point of all that boilerplate? So u can use devtools? So u can use off-the-shelf middleware to speed up ur dev? RAPID app development? Cause in a few years those tools wont be supported, and u will be stuck with a legacy boilerplate mess.
i argue that a FULLY event-sourced model would negative all this and make everything scale without any tricks. The diciple of event-sourcing will negate the need of immutability in every case. Additionally the cognitive load of "events, reducers and reference equality" is very different from "events, reducers and events".
Go all with event sourced ___domain models and get all the benifits. Represent the way your ___domain does. Represent ur state changes to your ___domain with events. Make an event heirarchy so u can preciesesly update ur UI around its state transitions.
If redux persisted events INSTEAD of the composed state, none of these problems would exist AND you would get time-travel. Then u can snap-shot ur state periodically to reduce load times.
Instead redux uses events to trigger state changes, and snapshot diff'ing to trigger ui changes.
redux is the best you can get in JavaScript for functional UI coding ... but clojurescript+reframe utterly destroys js+redux on every feature (in the context of making functional web apps)
`setState` doesn't actually care whether you've mutated your data or updated it immutably. In fact, I just ran a quick test, and you can even directly mutate your state object and then call `this.setState({})`, and it will update. `setState` is basically a combination of "queue an update to `this.state`, and queue a re-render along with that". So, if you mutate `this.state` and then re-render, your render output would be "correct" because the state object was updated.
Where immutability really comes into play with React itself is optimizations via `shouldComponentUpdate`. The fastest way to determine if a component needs to update is shallow equality comparisons of current and next props/state, which requires that you do immutable data updates to produce new object references. Two good articles on the topic are [0] and [1].
> setState doesn't actually care whether you've mutated your data or updated it immutably.
Not necessarily - if something downstream is looking at the values (such as a shouldComponentUpdate check), the first mutation may cause the current value to === the next value and prevent a render. I know you called this out as an "optimization" but you don't always know what's happening inside your components, especially if 3rd party libraries are involved.
That's what I was saying. The actual `setState()` function can be called with new references from immutable data, the same references that already existed but were mutated, or even no references at all if you mutated. So, literally, `setState()` does not care what process you used to potentially update data before calling it - it just applies a shallow merge of whatever object you passed in to the existing `this.state` object, and then queues a re-render. It's the _rest_ of your code that might care.
The primary reasons to actually update data immutably before calling `setState` are for easy and consistent implementation of `shouldComponentUpdate` / use of `PureComponent`, and general FP principles that immutability should be preferred over mutation.
> 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)?
I've seen some people say that you should put literally every single value in your app into Redux. You certainly _can_ do that, but I would see it as overkill. I'm much more pragmatic about it - put it into Redux if it makes sense to, per the rules of thumb in the FAQ.
> 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)?
Won't having half your state outside the store and the other half inside add unneeded complexity and make your code even more difficult to read?
The most common (and to me, reasonable) situation would be to keep all fetched data in Redux, any other app state that needs to be referenced by multiple components, and possibly some bits of UI state as needed (like "currently showing a modal for editing an item"). Component state would be primarily used for "is this dropdown open"-type values.
But, as I said, it's totally up to you to decide what lives where :)
Another way to look at it: What data is OK to lose if you refresh the page? That to me is component state. You don't have a url: '.../?dropdown.001=open' / '.../?dropdown.001=closed' so that's likely purely component state (not application state).
Very good point. Ditto with hot reloading components. React-Hot-Loader tries to retain component state via complex use of code transformation and "proxy" components, but it's very finicky and has lots of edge cases. Using the "plain" HMR API to just swap out the entire component tree on any component change is much simpler and more reliable, but doesn't preserve component state. Choosing to keep something in Redux so that it gets retained during that situation is a valid choice.
And it usually isn't anything as sane as half in the store and half in one other place.
It's like 70% in the store, and 5% in component#1, and 8% in component#2, and 16% in component#3 (duplicating some stuff from component#1 and sorta duplicating some stuff from component#2 with some notes that someone should refactor all this and move those to redux) and the rest of it is only god knows where.
And then there is some hard to track down UI bug because using setState() turns out to be really much slower than you think it is going to be.
But Redux is so boilerplatey and heavy handed that it made sense in each individual case to the original coder/reviewer to not use it.
It really depends on what you do. If you use component state in high-level components and pass it around a lot, yes it will likely lead to hard to understand code. But I see no issue with using state for state internal to low-level components, like an input field's value or whether a paragraph with a 'read more' button is expanded.
Of course, once you need to access a piece of state from outside that component you should probably move it to the store. But until then you are just creating unnecessary complexity by cluttering global state.
Just a tip to make that syntax a bit less ugly[0] Using babel / typescript
`a.b = c` becomes `Object.assign({}, a, { b = c })`
can be written as
`{...a, b: c}`
(this desugars in typescript to)
`Object.assign({}, a, { b: c });` [1]
(note also you had a minor typo there with equal sign {b=c} should be a colon, I feel like I make that mistake multiple times per day when writing typescript / javascript, having two different assignment operator characters in the language is not good imho. i'd prefer if it was all just `=`, that will never change at this point though. )
For your seconds example,
`store.dispatch({type: METHOD, data})`
perhaps the Proxy object[2] (which allows for delegation, method_missing like functionality) could be used to turn the calls back into store.method(data)
0: Beauty is in the eye of the beholder as they say.
Just to clarify (and pile on more pedantry?): it's a JS feature that is also implemented by TS, so while you're correct that it's not a TS feature, it's also not particular to Babel.
In fact, sometimes I like to use TS because it allows me to skip the Babel part of the process entirely.
> Just a tip to make that syntax a bit less ugly[0] Using babel / typescript
> `a.b = c` becomes `Object.assign({}, a, { b = c })`
> can be written as
> `{...a, b: c}`
That's very true, but it still not expressively correct in my eyes.
A dispatch is not really equivalent to a method call. A reducer can't have side effects, and must be synchronous. So you can be certain that the state is consistent immediately after the dispatch returns.
If you have complex action dispatchers the asynchronous logic is still contained in a single function. This is easier to test than a set of loosely coupled data objects that are firing of async events and calling each other through multiple levels of indirection.
Not to nitpick, because I believe I understand what you mean – but one of the things that bugs me about Redux is that a reducer absolutely CAN have side-effects. They're just "not supposed to".
So all it takes is one mistake or one new developer or whatever and suddenly all your assumptions break.
It's one of the essentials principles of redux [1] that reducers must be pure functions without side effects.
If you violate that principle, then yes, your assumptions break. That's why you should keep it in mind. You can't really blame the framework if you purposely go against its basic rules.
I just wish they had a reasonable way to _enforce_ those rules (though I understand it's not really possible) – or at least make people really go out of their way to break convention.
I have a similar feeling about Vuex in the Vue world. Trying to recreate the Elm architecture without Elm ends up being a bit awkward. It's not just immutability and pure functions, as others have noted, it's even more down to a lack in JavaScript of algebraic data types (tagged unions) and pattern matching. Without those, and other Elm language features, you end up getting some quite obscure looking and verbose code and "magic" strings all of which is difficult to type-check (e.g. Flow). Good old-fashioned singleton state modules work better for me.
> Also having a single store for all your data, definitely doesn't help with speed as a single event suddenly becomes an O(LogN) operation in the best case.
The store is usually pretty flat. Mostly a single object with a bunch of properties, some of which might be objects themselves. All of them are usually switch statements, and if the action isn't matching anything in the switch, it returns the default. Sometimes there are nested switches.
So realistically, considering the construct in play, you can do tens of thousands of calls to the reducers to get a new state every second.
Even if your store has a very deep tree, in 99.99% of cases the time required to update it is completely negligible compared to any re-render that React will need to do afterwards (even when the DOM doesn't actually get changed).
The 0.01% is if your action has to do some super-complicated computations to get the next state.
You can consider it as a tree, but it's usually not a tree in the conventional data structures sense. It's almost always of a constant depth, and so is, in fact O(1). The vast majority of Redux states look something like this:
{
todos: {
1: {},
2: {},
...
}
}
And so all references are O(1). Real applications often have much bigger and more complicated structures, but they're nearly always of constant depth.
Redux's `createStore` function doesn't care what value your root reducer returns - it could be plain JS objects or arrays, a single primitive value, Immutable.js objects, or even class instances. However, the common (and suggested) approach is to use the included `combineReducers` utility, which expects that your root state value is a plain JS object, and you can continue to use `combineReducers` to set up handling for nested state values. So yes, a typical Redux app state is indeed an object with various amounts of data attached to the state tree.
This doesn't really explain why it has to be that way. I'm not really a fan of "it is because it is" design.
It doesn't seem like there's any particular reason that a state reconstruction algorithm needs to be more expensive than O(1). What kind of advantages does this design have that an append store wouldn't give?
Redux was built as an implementation of the Flux Architecture. In Flux, you have different "stores" for different types of data (such as a `UsersStore`, `PostsStore`, and `CommentsStore`). One of the key concepts of Redux is that instead of having separate stores for each type of data, you can have separate "reducer functions" that are responsible for initializing and updating those data sets, and write another function that combines all of them together into a single object state tree. So, the standard encouraged approach is that the root reducer function delegates the work of updating each "slice" in the state tree to smaller functions, and so on ad infinitum. That way, each individual slice reducer function can be written and understood in isolation.
My blog post "The Tao of Redux, Part 1 - Implementation and Intent" goes into a lot of detail on the history, design, and influences behind Redux [0], and Dan's post "You Might Not Need Redux" [1] talks about the tradeoffs that Redux asks you to make and the kinds of benefits you get in return.
Arrays end up being a bigger pain to deal with when updating.
If the User marks TODO item #17 as complete (or deletes it), you have to either dig through the state array looking for the TODO with the matching ID, which is O(n), right? I'm sure there are times an array is more conventient. These trade offs are in the redux docs.
And this is one of many reasons why Redux encourages you to normalize your state - you can retrieve any item with a couple simple direct lookups (such as `state.entities[type].byId[id]`), rather than mapping over an array comparing item IDs. Granted, O(n) array loops aren't likely to be a real perf issue until you hit fairly large values of N.
Redux absolutely _is_ an implementation of the Flux Architecture. I've described it as "Flux taken to its logical conclusion". If you read my post "The Tao of Redux, Part 1 - Implementation and Intent" [0], I quote several comments and pieces of early documentation that back up Redux's Flux heritage. Redux inherited the idea of plain action objects with a `type` field, action creators, and the concept of "dispatching"
Pretty good summary of the main points for good React-Redux performance. I will say that I'm not a fan of writing `mapState` functions inline in `connect`, as it makes it harder to read them (especially with that parameter destructuring in those examples). But, good post. I frequently see people ask what's wrong with just connecting the top-most component, and you've captured the main reasons why that's bad for perf. And yes, you absolutely should use memoized selectors in your `mapState` functions.
If anyone's interested, I discussed related aspects of good Redux performance in my blog post "Practical Redux, Part 6: Connected Lists, Forms, and Performance" [0], and have a lot of other articles on both React and Redux performance topics in my links list at [1]. Also, my post "Practical Redux, Part 7: Form Change Handling" [2] specifically shows off a React component I built to buffer change events from text inputs to help improve UI performance.
I switched to MobX and can't be happier. Performance is never a problem and everything is just simpler and easier to understand. I think you should give MobX a shot.
> mobx-state-tree is a state container that combines the simplicity and ease of mutable data with the traceability of immutable data and the reactiveness and performance of observable data.
Preethi Kasireddy did a fantastic presentation at ReactConf comparing Redux and MobX [0], Robin Wieruch wrote a good article comparing them last year [1], there was a Reddit thread with good discussion as well [2], and I have links to more comparisons at [3].
They're different tools taking very different approaches to solving the same kinds of problems, and they definitely appeal to different developers.
Yup. Redux also fits better people who like more vanilla code at the expense of verbosity. MobX fits better people to prefer terseness.
Redux falls apart pretty hard when people start layering sugar and abstractions on top. It's my pattern of choice, but for teams that insist on abstracting the Redux boilerplate away, I steer them to MobX.
Yep. Redux does a great job of pushing mutation out of your application logic and into the library machinery, much like React does. Together, you get logic that's remarkably pure. It makes for an application that's dead simple to debug.
I've never tried MobX, but it looks pretty impressive too. I can imagine it working really well if you have the discipline to not leak your mutations all over the place.
MobX (in strict mode) forces you to annotate your mutations (via the @action decorator).
MobX is useful mostly as the data model / selector part of redux. It does an awesome job of it. Once you've defined your core data model, you can create layers of computed properties and transformations out to your view. The view then rerenders in a really optimal way.
Where redux shines is the prescriptive nature. The layout of a redux app is fairly well defined at this stage and there are "right" and "wrong" places to put (and look for) different types of code.
With MobX there's still no clear way to layout your application, so, as you say, you need to be more disciplined with your approach.
I've found the opposite. Coming from FP like Clojure, Redux just feels unwieldy in comparison, whereas MobX feels like it fits the language/problem better (but has plenty of it's own issues)
Same thoughts here about MobX. I tried my best to like Redux from my early on React days but could never get myself to like it, Mobx on the other hand has been a way more pleasurable and productive experience. I don't know or understand much about the pros and cons around Immutability and FP paradigm of Redux, but I sure can ship my apps faster and quicker using Mobx - which for a small bootstrapped startup like mine could mean the difference between life and death.
After having used Mobx for more than 10 months now, I still have to find areas that I dislike about Mobx.
As others have said, it does allow you to get much messier with your code than the rigid structure of Redux so you have to be more careful with your structure. My first MobX app was (and in some ways still is) a bit of a mess in spots.
That said, my subsequent apps have gone much better and I definitely prefer it to Redux, but I can see the appeal of Redux's more structured approach.
A few months ago I read the the article from the redux-creator who sais that you should only use redux if you really need it. I found out that most of my trubbles came from the fact that I should not have used redux.
I lately removed it and am now using rxdb for things that have to be state-like and persistent. For everything else I just use reacts setState on the plain components.
The most common complaints are about UI refresh performance in a React-Redux app, particularly if you're dispatching an action for every keystroke in a text input. The original post we're commenting on covers several aspects of good performance, and my other comment in this thread at https://news.ycombinator.com/item?id=14706509 has links to benchmarks and more info on various performance scenarios and optimizations.
It basically tries to enforces a few old ideas, pure functions, message passing and immutability, with no help from the language, which results in verbose and ugly code.
`a.b = c` becomes `Object.assign({}, a, { b = c })`
and
`object.method(data)` becomes `store.dispatch({type: METHOD, data})` with the implementation code of the "object" being a huge "switch" statement.
If you want immutability, pure functions and message passing, then why not use a language that is build around them and make your life easier? Clojurescript maybe?
Also having a single store for all your data, definitely doesn't help with speed as a single event suddenly becomes an O(LogN) operation in the best case.