Step by Step Guide to Building React Redux Apps | Hacker News Reader

Step by Step Guide to Building React Redux Apps

medium.com

133 pointsnode-bayarea29 comments

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...

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.

Not counting other parts of its API like combineReducers and subscribing listeners, Redux is essentially..

function createStore(reducer, initialState) { let state = initialState; return { dispatch(action) { state = reducer(state, action); }, getState() { return state; } } }

It's quite simple.. and yes, it should only be used when needed, but the whole implementation of the Redux part of an app can exist in a few lines in a single file.

Sorry, the formatting for that didn't come out right

You need four-spaced indents to create code blocks.

I guess the "predictable single state container" is the key of its success as well as its great presentation videos.

While I understand your point, that's not entirely true; Redux itself is just a state management library, and thus _completely_ decoupled from React. You can use it with any other library/framework. In order for Redux to work with React, you need the _connector_ library, "react-redux".

Furthermore, Redux itself is a relatively small library, written in a heavily functional style. True, this may be hard to wrap one's head around for developers new to this, but I can think of no better place to learn due to not only the small size, but a lot of documentation and _very_ active involvement (in GH issues and StackOverflow) by it's author.

MobX is a nice alternative paradigm to Redux that is gaining traction in the React community. It allows you to declare your data as observable, so that components can update automatically to changes.

https://github.com/mobxjs/mobx

Thanks so much for sharing this, it's exactly what I've been looking for, coming from working with Meteor for a while.

this is looks really sweet. Is there a list anywhere of what type of app makes sense with mobX vs redux?

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...) and downsides (http://stackoverflow.com/questions/32021763/what-could-be-th...) 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.

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.

Another commenter added the sentence I wish I had put in the original post. What I meant to say was, start with mostly pure components and just hold state in some top-level react components. Don't use react or flux. React makes it easy to share state between parent and child using props and callback registration which is perfectly fine to start.

When you find it hard to understand your state management within some parent react containers, or you're sharing a lot of state between siblings, consider flux or redux. Not before.

I think the functional style used in the redux codebase makes it a bit less obvious for those not accustomed to the style.

But it's really extremely simple. The terminology is perhaps more abstract than one might prefer, but I have yet to think of a way to improve upon it.

Also, if you let most components be pure, it's easy to start with a stateful component or two and then add redux later.

I really wish I had included your last sentence in my original post. Start with pure components and just React.

I think that's the best practice anyway.

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...

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.

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});

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.

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

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?

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.

Why would they dissuade? Is subscribing considered as anti-pattern?

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

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.

Nope. Redux does require that your reducers update their state immutably, but does not care HOW you do so. You can do it with Object.assign() / _.extend(), array slicing, the object spread operator, Immutable.js, the React Immutability Helpers, or one of the umpteen libs that provide abstractions for immutable updates like dot-prop-immutable or object-immutable-path.

A better solution would be to use React Redux that does this and many other optimizations for you :-)

You can use reselect in combination with react-redux for a similar effect. Reselect declares a view of the state, and react-redux manages connecting the component to this view.

I would say redux differs from baobab in not enforcing a state structure that mirrors the component tree. So it might be that if your state structure matches the component tree baobab is the simpler way, and redux is better if you need to decouple them.

I'm using redux with a structure nothing like the component tree. I ended up keeping updates and the tree trivial and keep all logic related to how to present the data in selectors (Reselect). Ending up with a structure not unlike the reflux implementation i was migrating from ;) to isolate parts of the state i have all subtrees export getters and actions so that reselect selectors works with the root getter for the subtree.

Reply on news.ycombinator.com