For me, read everything you can, try to remember the bullet points, and later on, when you have a chance or use case, give it a try.
Some things take more buy in... React can be brought into a project in pieces... but after a while, you're best off with other tooling in addition, Babel and a bundler become nearly indispensable (it took me a while to warm to Webpack over Browserify though).
I was just arguing with a coworker a few days ago that "async" functions were imminent, and since we're using babel anyway that we should go ahead and use them.
I don't have anything... I had to do some checks for the actual route, the router, and in the redux engine... It was about 6 months ago tbh and I just remember it was wild getting it to sync between the router and the redux... I had to hack a listener for route changes, then trigger an action into the store.
I'm not longer working in the group that was on the project...
One of the hardest issues I had with redux + ng2 was actually trying to integrate the ng2 router with redux, I wanted to keep the route and params in redux, so that my components could all reference from the same location for all state.
Keeping the store and router synchronized was pretty painful to say the least... Hopefully the next article in this series touches on that.
While interesting.. I would think that something using a promises interface, and beyond that, having a template string parser would be more eloquent at this point.
Kind of a sad moment, but I'm glad Tim was able to pass the project along. Too many times a project just dies on the vine. I can't imagine how relatively painful moment must have been to get to where it is, and how much work it is. Date-time logic is some of the most difficult to get right, especially when you add in various locals and options.
Just today, I've been working around issues by replacing a bunch of custom logic with moment.
CJS/Node modules really can only work via pre-bundling solutions... AMD is pretty bad in it's own right as well, though slightly better for the browser case.
The ES2015 module syntax offers the ability to determine loading as a pre-process step. Though in practice most aren't using proper reference paths, so you're stuck using pre-bundling, similar to CJS. Also, you can't conditionally require modules as you can with CJS. Some benefits are the ability to have better tree shaking with bundlers. As it stands, the tooling is a work in progress.
If ES2015 modules were supported in browsers from earlier on, then they would have been used over either CJS or AMD. And HTTP2 would have been *HUGE* in terms of performance.
It feels like this is slightly less of an abstraction than Redux (which itself is pretty small), with a slightly less clean abstraction, and more inconsistent to extend.
It's an interesting idea, just the same, I just don't think it's quite as good. There's nothing stopping one from using multiple Redux stores in an application, but that's a YMMV kind of thing.