
Step by Step Guide to Building React Redux Apps - node-bayarea
https://medium.com/@rajaraodv/step-by-step-guide-to-building-react-redux-apps-using-mocks-48ca0f47f9a#.5qbuaxkrf
======
afarrell
If you want a guide to doing this with a "here are some specific libraries we
will use today" perspective and automated testing, take a look at
[http://teropa.info/blog/2015/09/10/full-stack-redux-
tutorial...](http://teropa.info/blog/2015/09/10/full-stack-redux-
tutorial.html)

------
gravitronic
It's really disappointing to me to see Redux being the "defacto standard" for
React applications. It's overly decoupled for simple applications, which makes
it harder to reason about the application. It also doesn't help that the Redux
codebase itself is hard to understand.

It is only a tool you should reach for after you find you need it. Too few
developers approach software development with this level of pragmatism and
instead we get "use X because it's being used". I guess you need to understand
the tool to know when to use it - but that doesn't mean it should become the
"defacto standard".

Ironically Redux is being coupled with React, which is a great library for
structuring UI into components and resulting it simpler to understand code.

~~~
barkingdog
I'm a little confused by what you're trying to say, so help me out here. You
say "it's overly decoupled for simple applications" and then "it is only a
tool you should reach for after you find you need it." This would imply that
you view Redux as a tool that primarily helps maintain larger React
applications -- does that mean you think it doesn't make sense as the defacto
standard as compared to, say, Flux? Or that there shouldn't be a defacto
standard, or that neither of these is a good enough defacto standard?

I'll take this as an opportune time to link to two very helpful and useful
posts about Redux from its author (Dan Abramov) about upsides
([http://stackoverflow.com/questions/32461229/why-use-redux-
ov...](http://stackoverflow.com/questions/32461229/why-use-redux-over-
facebook-flux)) and downsides
([http://stackoverflow.com/questions/32021763/what-could-be-
th...](http://stackoverflow.com/questions/32021763/what-could-be-the-
downsides-of-using-redux-instead-of-flux/32916602#32916602)) of using Redux.

Namely, I see Redux offering a nice advantage over flux in encouraging reducer
composition (and functional purity) for modularity. "This pattern also enables
wonderful features like no-user-code undo/redo. Can you imagine plugging
Undo/Redo into a Flux app being two lines of code? Hardly. With Redux, it
is—again, thanks to reducer composition pattern. I need to highlight there's
nothing new about it—this is the pattern pioneered and described in detail in
Elm Architecture which was itself influenced by Flux."

In short, the key value add for Redux, is not necessarily that it's
(overly/inadequately) decoupled, but that it is necessarily forcing a
decoupling via functional purity for the /purpose/ of modularity. That is, it
is taking a more functional approach to state management for React components,
favoring the event log paradigm rather than black box paradigm. This brings
with it the ability to be "designed with use cases such as logging, support
for Promises, Observables, routing, immutability dev checks, persistence, etc,
in mind." Of course, these aren't impossible with Flux, but these things
follow intrinsically from Redux.

Take my opinion with a grain of salt because I'm not super experienced with
Redux yet, but I really like what I've seen so far playing with it.

~~~
Retozi
I believe what he is trying to say is this:

It will take a person a couple of days to "grok" Redux, and a quite a bit
longer to fully understand the ins and outs so one can make informed,
confident decisions on how to solve problems "the Redux way".

Now you gain "cool" things by doing it, but here is the catch: Is the benefit
worth the time investment to get there?

His argument is that for a lot of simple apps it isn't. You get very far with
plain React, and a project has to have significant complexity to pay back the
costs of fully understanding Redux.

I would argue a lot of people picking the React ecosystem make the mistake of
choosing too much architectural complexity, not too little.

The extreme pluggability helps to broaden usage of Redux. But it is overkill
for many projects. Decoupling is important, but it is not free (see parts of
the Java ecosystem).

Devs should consciously decide what to introduce, and leave out stuff that
simply doesn't increase development efficiency given the nature of their
project.

------
akrymski
Wow what an absolute nightmare to wrap my head around. Reminds me of J2EE days
of abstract patterns everywhere just because we can. Talk about simplicity.

Here is the same app in 130 lines:

[https://github.com/techlayer/espresso.js/blob/master/example...](https://github.com/techlayer/espresso.js/blob/master/examples/todomvc/app.js)

~~~
rahimnathwani
The author addresses this point early on: "... earlier frameworks made
building Todo apps simple but real apps hard. But React Redux make building
Todo apps hard but real productions apps simple."

I don't think the author advocates using react-redux for the simplest todo
list app.

------
jsprogrammer
The "action creators" from step 4 can be further reduced:

    
    
        export const addTodo =
         text => ({
          type: 'ADD_TODO',
          id: nextTodoId++,
          text,
          completed: false
         });
     
        export const setVisibilityFilter =
         filter => ({type: 'SET_VISIBILITY_FILTER', filter});
     
        export const toggleTodo =
         id => ({type: 'TOGGLE_TODO', id});

------
aldanor
I think the funniest part is that the _total_ number of meaningful lines in
Redux source code is less than 250. Compare that to the supplied documentation
with over 6,000 lines of Markdown.

If you have any FP background, this is really nothing innovative, more of a
common sense kind of thing. With the main achievement being that it's trivial
enough and has nice documentation with examples so that mass JS programmers
can actually grok it...

I've nothing against Redux, it's a good idea but quite a bit overhyped is all.

~~~
novaleaf
also the amount of boilerplate needed to use redux leaves a lot to be desired.

------
iliaznk
Has anybody tried both Redux and Baobab? If so, do you think Redux is better
and why? I'm using Baobab in a couple of projects and really liking it, but
Redux from the tutorial I read seems to a bit too general to me. In Baobab you
can subscribe components to their particular branches and only those
components will re-render if the branches change.

In Redux, it seems to me, there's no way you can do it, or at least nothing is
provided out of the box. Am i correct?

~~~
Bromlife
I accomplish this in Redux with a simple:

    
    
        componentDidMount() {
            item = store.getState().get('item')  // Get function from Immutable.js
            this.unsubscribe = store.subscribe(() => {
                let nowItem = store.getState().get('item');
                if (item !== nowItem) {
                    this.forceUpdate();
                    item = nowItem;
                }
            });
        }
    

Someone may have a better solution, but I think this works fine for my needs.
The internet is full of people dissuading redux users from subscribing to
actions.

~~~
iliaznk
Oh, I see, Redux also requires Immutable.js to work, correct?

~~~
vkjv
Reduce requires that functions be pure (no side effects). Immutable.js is one
way to enforce this but ithe is not required.

The examples mostly use things like the spread operator and Object.assign.

