14 comments

[ 2.5 ms ] story [ 32.2 ms ] thread
I know that a lot of people have complained about the "boilerplate" that Redux involves, but as Dan Abramov said in "You Might Not Need Redux" [0], there's tradeoffs involved. Redux asks that you write your code with some constraints, and those constraints in turn open up some interesting possibilities. Time-travel debugging is one of them. May not be useful for _every_ scenario, but I've certainly found it incredibly helpful in my own app. @mdiordiev has done a fantastic job taking the DevTools core that Dan built and the Monitor UIs built by the community, and wrapping those up into a cohesive tool that makes the debugging experience even better.

For anyone out there looking to get started with Redux, I keep a big list of links to high-quality tutorials, articles, and resources for React, Redux, and related topics [1] - specifically intended as a great starting point for anyone trying to learn the ecosystem, and a reference for more advanced techniques and topics. I also have a catalog of Redux-related addons and utilities as well [2].

[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

[1] https://github.com/markerikson/react-redux-links

[2] https://github.com/markerikson/redux-ecosystem-links

Just to say the previous title was more informative: "Better time travelling in Redux Devtools", or something like this. I didn't know about "time-travelling" debugging and I was curious to learn about it, that's why I clicked. "changes in the Graph Monitor" doesn't talk to me at all.
Redux may not be the greatest and the most innovative technology. But I love the community around it. Bringing always something new and progressing in steady pace.
Yep. I think a large part of Redux's success is the genius decisions that Dan and Andrew made during its initial development. Keep the core API minimal, apply functional programming principles where possible, and provide primitives and hooks that allow others to build extensions for their own specific use cases. (The fact that they're both extremely nice and well-respected people doesn't hurt either :) )
IMHO, Redux introduced a gamechanging concept no other JS library has done before (at least not in this big way): Single and immutable state object. This fact alone makes the developer experience significantly better, both in shorter debugging time (and less bugs to begin with) and piece of mind that the code works as intended.
what about elm? didn't redux just take basic concepts from elm and implemented them in vanilla js? Not saying that Dan didn't do amazing work anyway.
what about elm? didn't redux just take basic concepts from elm and adopted for js (and react).
The greatness of Redux comes from it's blinding simplicity.

It is the kind of simplicity that I am happy to use the word genius to describe.

Has anyone here used Redux for very large applications? I'm curious if scales well beyond a few devs and 100 reducers and actions.
Very much so... it's a very good fit (though how you extend things will vary) from just past trivial projects, to fairly large. Very few projects are too large for redux to be a decent fit.
The extension can be used apart from Redux, with any architecture which handles the state. Just connect to it and send actions and states. There's an implementation for MobX [1], for Angular ngrx [2], for RethinkDB Horizon [3].

Here's a post with more details: https://medium.com/@zalmoxis/redux-devtools-without-redux-or...

Except Chrome, Firefox and Electron extensions, it can be used also remotely from React Native or even from the backend.

[1]: https://github.com/zalmoxisus/mobx-remotedev

[2]: https://github.com/ngrx/store-devtools

[3]: https://github.com/zalmoxisus/horizon-remotedev

This is precisely why I've been pushing for Redux even outside of the React ecosystem. I've been talking to quite a few people interviewing for ng2 projects... regardless of my opinions on ng2, something like Redux is probably a good idea for most projects (beyond trivial complexity, to relatively large).