
Learn how to use Redux step-by-step - bryanrasmussen
https://github.com/happypoulp/redux-tutorial
======
spapas82
You may also want to take a look at my own redux tutorial
[https://spapas.github.io/2016/03/02/react-redux-
tutorial/](https://spapas.github.io/2016/03/02/react-redux-tutorial/)

~~~
krishanath
So what is the problem solved by Redux? I don't see a simple explanation of
that in your write up. Most people struggle when asked this question. Some
people go on about "time travel" and other fancy things that have nothing to
do with the business problem you're trying to solve. Other people talk about
"single source of truth" as if that didn't exist before Redux.

~~~
spapas82
This was a really long article so you may probably missed my reasoning for
using redux. I'm copying from the "Introduction to redux section" (which comes
right after the "Introduction"):

"I have to say that I got interested in redux because of all that buzz this
framework generated. However, I got really interested in it when I understood
how close its philosophy was to functional programming - this, when combined
with the usage of react functional components will enable you to write great
code and (most important for me) really enjoy coding with it [...]"

So, for me the reason for using redux is its functional programming related
philosophy. Ofcourse there are other js frameworks that are more functional
(in the fp meaning of the word functional) like hyperapp, choo and definitely
many others I'm not aware of but most of them built on the concepts of react
functional components and redux, and redux is much more popular.

~~~
krishanath
Sorry, to me that's an unsatisfying answer. You are not saying what problem
redux is solving for you. "It is like functional programming" does not even
attempt to explain what the problem being solved is.

~~~
acemarke
To answer the "functional programming" aspect:

First, "pure functions" are generally agreed to be easier to test and easier
to understand, because they only rely on their inputs, and don't modify
anything outside of the function. In a real application of any kind, you
realistically can't write the entire app as pure functions. But, writing more
of your codebase as pure functions means more of it is easily testable and
understandable overall.

Second, while the OOP vs FP debate is never-ending, FP does lead to some nice
forms of reusability via composition.

With Redux, you are intended to write your "reducers" as pure functions. It's
up to you whether those reducers have complex logic or simply return the
values they were given in the actions, but the reducers (which control the
actual state updates) should all be pure, and therefore easily testable and
understandable. Reducers can also be composed together to add new behaviors,
such as:

    
    
        const finalUsersReducer = undoable(resettable(originalUsersReducer));
    

In addition, writing pure functions with no side effects, in conjunction with
dispatching plain object actions, is what makes Redux's time travel debugging
feasible. (That's not to say it's impossible to implement time travel in other
ways, just that those aspects of Redux's design make it very straightforward
to implement time travel.)

------
guptagaruda
Great tutorial.

I recently published an overview of Redux here -
[https://medium.com/@guptagaruda/introduction-to-redux-and-
mo...](https://medium.com/@guptagaruda/introduction-to-redux-and-
mobx-e6fa98b6479)

~~~
krishanath
Holding application state in a tree is nothing new. It is as old as software
development itself. You don't need Redux for that. Actions and reducers are
not solving any problems. If your application needs undo/redo then that's
understandable otherwise get/set methods are all you need.

~~~
guptagaruda
Redux is just one piece of the puzzle. Let me try to explain the problem it
solves. Let's say if you are building a complex SPA with lot of UI components
in the view and state changes impacts several parts of the view. You can build
this view in several ways:

* Plain javascript with jquery - We can surely achieve it but the code quickly becomes a soup of callbacks and events handlers. After a while the code becomes unmanageable. This is pretty much the approach you're suggesting with getters/setters.

* AngularJS's dirty checking is one solution. It works and the code scales in large teams but perf suffers in complex views due to costly digests. It doesn't provide a way to conditionally exclude a sub-view from the digest cycle. This will become the main bottleneck (for perf) as the application grows.

* React and Angular 2/4 - React (shouldcomponentupdate) and Angular 2/4 (onpush change detection) leverages immutability very well to cut down re-render cycles. This is where Redux shines with its immutable way of changing state. It's uni-directional flow is another great benefit to keep the entire flow predictable and maintainable.

I am not saying all these things are needed for every SPA app out there. But
these optimizations are needed for complex and performance sensitive
applications. Check this out - [https://medium.com/@dan_abramov/you-might-not-
need-redux-be4...](https://medium.com/@dan_abramov/you-might-not-need-redux-
be46360cf367)

Also, I know keeping application state as a single state tree is nothing new.
I started this side project
([https://github.com/guptag/FinCharts](https://github.com/guptag/FinCharts))
almost four years ago with React/Immutable.js without any state management
libraries (recently moved to electron from nodewebkit). But this code won't
scale in large teams (entire ui state is declared in one file, cannot extend
the functionality like Redux's middleware support etc).

~~~
krishanath
No, if you get/set methods that doesn't imply javascript with jquery! I am
using React, but not ReactRouter or Redux. I hold my application state in a
tree, and the tree nodes have get/set methods. My state tree is not immutable.
I think "immutable way of changing state" is an oxymoron.

~~~
eropple
How do you trace and replay state changes when debugging?

~~~
devdad
Not the one being asked, but I usually go with breakpoints in Dev Tools.

~~~
eropple
Breakpoints cannot _replay_. They can pause and continue playing.

The inability to examine a time series of data after-the-fact and resume from
any point makes this approach significantly, significantly worse. Like, I've
done it just as you have, and I'd under no circumstances go back. It's so bad
that I've basically built action-pattern systems in other languages (before
using Redux, actually).

Functional tooling and composition with managed side effects is _fucking
awesome_ and doing otherwise verges on footgunning if it doesn't camp right
out there.

~~~
devdad
I guess you must be having a whole different set of problems than me. I also
use Redux, have not found time travel to be a boost to my productivity. I
choose Redux because of the simplicity around state management, and having it
all centralised in a store is a nice pattern. (Don't really get other
commenters claiming that this isn't new - I don't see the relevance).

------
whitefish
Redux is unnecessary complexity. Anyone considering it, please do yourself a
favor: check out an MVC framework and see how simple it is. Remember, when
React first came out they described at as "React is the V in MVC." Adopt MVC
in your project and watch your productivity soar.

Note: Some people believe that MVC implies two-way data binding. This is
false.

~~~
vletmixutechre
I've spent most of my time as a back end developer, occasionally dabbling in
some front end code in various MVC frameworks. I always hated it and found it
to be tedious.

I recently took up react+redux for a new project and for the first time feel
like I'm developing for the UI in a way that makes sense and feel like I'm
able to accomplish things way faster than with other clunky frameworks.

~~~
whitefish
Which Javascript MVC framework did you use? Some people who used Angular hated
it and conclude that MVC is horrible. No, Angular is horrible, not MVC.

~~~
vletmixutechre
Yeah, I spent some time with Angular as well as Backbone/Marionette

------
acemarke
This tutorial is pretty good, if a bit quirkily formatted.

I'm a Redux maintainer, and I'd like to toss out a bunch of additional
resources for learning Redux.

First, I do recommend that people start by reading the official docs [0], and
watching Dan Abramov's videos on Egghead [1].

Next, I keep a big list of links to high-quality tutorials and articles on
React, Redux, and related topics, at [2] . Specifically intended to be a great
starting point for anyone trying to learn the ecosystem, as well as a solid
source of good info on more advanced topics. It includes links for learning
core Javascript (ES5), modern Javascript (ES6+), React, Redux, and much more.
The list has a category containing many other Redux tutorials [3] (and the
tutorial linked here is already in that list).

I published an "Intro to React (and Redux)" presentation at [4] , which is a
good overview of the basic concepts for both React and Redux. I also
frequently publish blog posts on Redux-related topics. I have a tutorial
series on my blog called "Practical Redux" [5], which is intended to
demonstrate a variety of useful React+Redux concepts and techniques in the
context of a sample application, and my "Idiomatic Redux" blog series [6]
discusses things like why certain Redux usage patterns exist in the first
place, and why I consider certain approaches to be good or bad

I highly recommend that anyone interested in React or Redux check out the
Reactiflux chat channels on Discord [7]. It's a great place to hang out,
learn, and ask questions, and there's always some people online who are happy
to help answer questions. I'm usually online there evenings US EST.

Finally, I personally am always happy to answer questions about how to learn
or use React and Redux. Please feel free to ping me on Reactiflux, Twitter,
Reddit, HN, or anywhere else you happen to see me :) I'm also keeper of the
Redux docs, and always open to suggestions for improvements and offers to help
make them better.

[0] [http://redux.js.org/](http://redux.js.org/)

[1] [https://egghead.io/series/getting-started-with-
redux](https://egghead.io/series/getting-started-with-redux)

[2] [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)

[3] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/redux-tutorials.md)

[4] [http://blog.isquaredsoftware.com/2017/02/presentation-
react-...](http://blog.isquaredsoftware.com/2017/02/presentation-react-redux-
intro/)

[5] [http://blog.isquaredsoftware.com/series/practical-
redux/](http://blog.isquaredsoftware.com/series/practical-redux/)

[6] [http://blog.isquaredsoftware.com/series/idiomatic-
redux](http://blog.isquaredsoftware.com/series/idiomatic-redux)

[7] [https://www.reactiflux.com](https://www.reactiflux.com)

------
abledon
For small projects it can sometimes be heavy weight , especially making all
those 'best practice' container modules / action modules .

