jdeal

Federal loan limits for the first year of undergrad are $5,500 for dependents and $9,500 for independents, so they can’t be blamed for a single year costing $100K.

Personally, I find that when boilerplate gets out of control, you can do one of two things, probably in this order:

1. Write helpers. 2. Write middleware.

The first is zero magic, and allows you to opt-in to abstractions as needed. The latter is more powerful and can remove pretty much any boilerplate, but you have to be careful about introducing too much magic.

Redux isn't much different than any other code you might write. If you prematurely abstract, you could create a leaky abstraction, and you'll have to unroll the whole thing. If you don't abstract at all, and copy-pasta everything, you're also going to have a bad time.

I think it's definitely worth considering other solutions, as Dan himself has mentioned that Redux isn't for everyone. Redux forces you to apply some constraints and make some tradeoffs. I personally like those constraints and tradeoffs, but I can understand it's not for everyone!

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.

Thanks again, Mark!

Maybe it depends on your definition of "re-render". When I say re-render, I mean getting React to run your render method, in which you're returning React elements.

By default, shouldComponentUpdate always returns true, so if a component re-renders, meaning you change state or props for that component, your render method is called again, and then all the child components (unless shouldComponentUpdate has been overridden) will also in turn have their render methods called. This will happen regardless of whether or not the props are the same. In fact, I often do this at the top, just calling setState with the same props (to a mutable object) to kick off another render.

This is all just JavaScript though and so is very fast. React is then mapping these elements to DOM nodes (which is slow). For that, it uses a very smart diffing algorithm to determine which DOM nodes need to be changed. (Maybe that's your definition of re-render.) So only the DOM elements that have actually changed get touched.

You can, if you want, use the PureRenderMixin to make React only re-render if the props or state actually change. The mixin just leverages shouldComponentUpdate to do this. This can be a bit of a can of worms though, so I kept this out of my beginnerish post.