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.
The README is a lot more matter-of-fact if that's your taste: https://github.com/jdeal/qim. I tried to have a bit more fun with the blog post and avoid simply rewriting the docs.
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.
MobX is really cool, and I wouldn't try to convince anybody not to use it if it works for them. I happen to be pretty religious about immutable data, having been bitten by problems with shared mutable state so many times. I know MobX has actions which help a lot, but I still like the core simplicity of Redux, even if it means more typing.
My dream would be to have David Nolen (of ClojureScript) and Michel Weststrate (of MobX) do a panel where they discuss the essential differences and pros and cons of each approach. The philosophies seem at odds, but I think there's probably a core truth that neither side has fully reached.
Also, I think the core lacking thing of Redux is that it isn't really composable like React. I'm really curious to check out https://github.com/FormidableLabs/freactal since it aims to be a fractal (composable) alternative.
(And yes, props to Elm for having a built-in composable architecture.)
There is no immutable state, at best we have immutable data. Benefit of immutable data is you can inspect two different states when state transitions from state A to state B. You get time travel and all that with this basic concept.
MobX makes it very easy to do that inspection between states.
Don't look at mutable state as evil. Redux state is mutable too.
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.
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.
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 :)
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.
