Hacker News new | past | comments | ask | show | jobs | submit login

If anyone is interested in learning this content through an in-depth video tutorial, I highly recommend Dan Abramov's two-hour "Getting Started with Redux" [1] and the excellent follow-up "Building React Applications with Idiomatic Redux" [2]. This is a great article, but learning Redux more thoroughly directly from the creator himself may be of interest to some!

[1] https://egghead.io/courses/getting-started-with-redux

[2] https://egghead.io/courses/building-react-applications-with-...




I came here to point out the Redux course by Dan Abramov on Egghead.io as well. I believe it's free. It's amazing how easy Dan makes it seem. It was a light bulb moment for me and finally made me understand the importance of immutability behind the React philosophy.


Would you mind expanding on that?


React's default behavior is that when a component re-renders, _everything_ underneath it in the component tree re-renders as well. If you want a component (and its descendants) to skip re-rendering, you can implement the `shouldComponentUpdate` method. You can put any logic you want into `sCU`, but the most common implementation is to compare the contents of `this.props` and `nextProps` to see if anything actually meaningfully changed.

You _can_ do a "deep equality" comparison that recurses through every nested field in both `this.props` and `nextProps`, but that's relatively expensive. The alternative is "shallow equality", which uses pointer/reference equality checks for each field in both objects. However, in order for that to be useful, you need to manage your data in an immutable fashion so that each update results in a new object/array reference, rather than directly modifying the existing objects.

So, you don't _have_ to manage data immutably in React, but doing so enables performance optimizations, and also goes along with React's functional programming influences.


For anyone interested, there's a great conference talk on this topic by Lee Byron from Facebook: https://www.youtube.com/watch?v=I7IdS-PbEgI


Gotcha - so you see it mostly as just a perf optimization based around SCU?

Funny timing. I was actually implementing SCU using deep obj equality for the first time earlier today. I did understand the desire for immutability, but it didn't seem to be a game changer.


Perf optimization is a big benefit, yes, but it also fits with functional programming principles in general.

React's `setState()` definitely doesn't care if you mutate or not - you can `.push()` right into an existing array in state, and re-set it into state to queue the re-render.

On the Redux side of things, immutability is important for several reasons. First, pure reducer functions are more easily testable. Second, they enable time-travel debugging - without immutability, jumping back and forth in state would cause the state contents to behave unpredictably, breaking time-travel. Third, the React-Redux `connect` function relies on immutability checks against the root of the state tree to see if it _thinks_ anything has changed, and against the return values of your `mapState` functions as well. If you mutate Redux state, your connected components usually won't re-render properly, because they think nothing has changed.


Just an fyi, if you are just doing a shallow comparison you can use React.PureComponent which will implement a shallow comparison sCU for you.


You're comparing reference to infer whether underlying data changed? Sounds really really fragile... Does the JavaScript language guarantee this or are you depending on the specific engine implementation? For instance will this still hold if the OS preempts the browser out and restores it later?


That's an absolutely standard practice in Javascript, and especially in the React world.

The assumption is that if two objects are different references, then their contents are also different. It's possible that you could have two different objects whose fields point to the exact same contents, but given a typical application setup that's unlikely. So, a simple `a === b` (or if you're looking at all the contents, `first.a === second.a && first.b === second.b && .....`) is just some quick pointer comparisons in the JS engine. So, at the JS level you don't care what the pointer address actually _is_, just whether the two variables point to different things in memory.


> their contents are also different

More precisely: may be different.


As I said, it's an "assumption" :)


Agreed, Dan's videos are great! Sometimes I've found people still thinking there's some magic going on inside Redux, so I just wanted to do my best to remove that.


Last summer I said to myself, "Okay I need to know what all the fuss is about." So I sat down and read the Redux source. I thought, "This is it?" It does almost nothing but issue loquacious console warnings when you're doing something you're not supposed to.

My conclusions were:

- it's as much of a discipline than a tool

- the complexity must be added by the middleware


The complexity is mostly from people approaching it from a confusing direction. Some of the naming is confusing ("action", but actually it's an event or message, is the worst one). Somehow everyone comes away from the tutorials and docs thinking that the typical code structure used in them has to be how you do it (see many of the complaints on this very page) as if it's much more a framework than a library.

I had a similar experience with it coming in to a recently-started React Native project at work, having not seen React, React Native, or Redux before. At first I was fairly confused (see: awful terminology, painful example code which everyone seems to take as gospel and which had, in fact, invaded our codebase).

Then I started to get an inkling that I was being tricked. I looked closer and... it's two event dispatchers. One of which it's mostly up to you to implement (the reducer). Plus a really short list of suggestions for how to write the code (mainly: don't screw with state in certain places/ways). That's it.

It's paper thin and dead simple, but somehow most people come away from the tutorials and docs hopelessly confused. I think there's something deeply and perhaps irredeemably wrong with the docs/tutorials and with the way Redux's proselytizers communicate. I can't figure out how else they could manage to confuse so many people about such a simple thing.


You've said that several times, and I'm genuinely asking: how should the docs handle things differently? If you have ideas and suggestions, _please_ file an issue or a PR and help us improve them!


The docs are fine. Redux is just a victim of its popularity. A lot of people jumping on it are people who are used to things like Rails, where there's one way to do things, every little bit of boilerplate is abstracted away (and if you don't want to do things this way, you're screwed) and you don't ask questions why.

Redux is the polar opposite. No amount of documentation will change that. The faster we accept that not every tool is the right one for everyone, the faster we can make better tools that are great and some stuff instead of being mediocre at everything.


I know it's not for everyone, and I know discussions won't convince everyone. I'd just like people who are complaining about the docs to offer some constructive help :)


I found the getting started with redux to be interesting once I already knew it. But when I was a newbie, I just found it to be confusing.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: