heygrady

// @remove-on-eject-begin
/**
 * Copyright (c) 2015-present, Facebook, Inc.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 */
// @remove-on-eject-end
'use strict';

heygrady

Managing fetch actions

If you are fetching data from a server, your app needs to manage that relationship. The redux manual demonstrates the need for at least three action: FETCH_REQUEST, FETCH_FAILURE, and FETCH_SUCCESS. The redux manual's reddit example shows a slightly different setup, omitting the FAILURE and renaming SUCCESS to RECEIVE_DATA.

Long story short, we need to expose the API data fetching lifecycle to our app.

Fetching lifycycle:

1. begin fetching
2. receive data or receive error (or bail when cancelled)

heygrady

Case Study: <Map /> and <List />

This is a case-study of sketching out a <Map /> (a Google Map) that shows pins and a sidebar <List /> that shows results. The two components are displaying the same data (items), side-by-side, in two different formats. If I make a change to list of items, both components need to update.

Features:

• Items
  • Shown as pins on the map
  • Shown as list items in the list
• Filter the list

heygrady

Refactoring for maintainability

There is no "right" way to do anything. Any best practice exists because it's been found by someone to be better than what they were doing before. Often there's a reason that one way is better... but no way is the perfect way. Everything has pitfalls.

If you've been working on a codebase — any code base — for more than a year, you have likely run into a few pitfalls. The decisions we make today have downstream consequences. It's difficult for young developers to tease out which choices will cause big problems in the future. It's difficult for seasoned developers to distinguish between how they usually do it and "the best way".

Best practices change all the time. Like any other type of technology, people are constantly finding ways to improve code. It can be a full time job keeping up with new developments... and emerging best practice don't always stick around. Anyone invested in the early days of ES6 may remember the hype around decorators. At the time they we

heygrady

Preloading data in a redux application

A redux app is a chicken and egg problem. Given a particular state, the app should render a certain thing. But... where does that state come from?

Starting from empty

Given a blank state, the app needs to rely on the URL to fetch the right data to populate the state.

In a server-side app, the initial state is determined in exactly this way. Given the initial URL, populate the state, render the app, send it to the client.

In a client-side app the situation is exactly the same, except it's totally different. On the client you have way more contextual information than just the URL. Given the URL, the current app state, a components own props and its internal state... a component must decide which data it needs loaded.

heygrady

Loading data in a react-redux app

This document covers the details of a component that needs to fetch required data before rendering. In our imaginary app we're using react, redux, and react-router. We're covering the specific use-case of a detail page that gets its id from the URL.

1. URL contains an ID, it is matched by a route like <Route path="/detail/:id" component={View} />, which renders our <View />
2. The <View /> component receives match in props. The match prop contains the ID in match.params.id.
3. The <View /> component renders some <MyContainer id={match.params.id} /> component with an id prop.
4. The <MyContainer id={match.params.id} /> container selects values from the state as props and passes them to the wrapped <My /> component.
5. When <My /> component's lifecycle encounters componentWillMount or componentWillReceiveProps, it calls an onBeforeRender function (passed in from mapDispatchToProps by <MyContainer />)
6. Then `` dispatches a

heygrady

Using react-router as a store

If you are building a react-redux application, you know that redux is the store. The state of your application should be kept in redux... but it's not the only store in your application. If you are using react-router (v4) you also have access to a "history store" — the URL of the current page hold valuable information about your application state.

We want to use react-router (v4) history to manage the state of the application too!

In a server-side react application, the URL is typically the only information available at render time. We populate the redux state using only the URL information we get from express. Treating the URL as a type of store has imortant implications in how you structure your app.

If you are truly dogmatic about only having one store to rule them all, you might enjoy react-router-redux. But it doesn't circumvent a key reality of a browser-based application:

heygrady

Managing URL State

In a react-router (v4) app you will inevitably need to manage the URL. This is one of those easy-hard things that react-router provides a basic API for and leaves the rest of the implementation up to the user.

The sticking point is that react-router location.search and location.hash are stored as strings. Older versions of react-router would parse these values into a location.query object that is no longer available.

If you need to work with query strings as objects you will need a library like query-string. This will allow you to parse the location.search and location.hash strings as objects. You can then stringify query objects back into search strings and use them in a <Link /> or history.push() call.

What libraries are we using?

heygrady

Redux containers: mapDispatchToProps

This document details some tips and tricks for creating redux containers. Specifically, this document is looking at the mapDispatchToProps argument of the connect function from [react-redux][react-redux]. There are many ways to write the same thing in redux. This gist covers the various forms that mapDispatchToProps can take.

heygrady

Using the classnames.bind method

Many people who work with React are familiar with the excellent classnames library. If you aren't familiar, it provides a simple function for gluing classnames together. In web programming in general, there are many times that we need to add or remove multiple classes based on conditional logic. The classnames library makes this easy.

More and more developers are embracing CSS Next and the power of CSS modules. However, when you add CSS modules to your react components, working with classnames gets more difficult. Typically, CSS modules is implemented with class name mangling. Transforming human readable class name strings into unique identifiers helps ensure that every class name in your app is unique.

This means that you can write your component CSS in isolation without worrying about the dreaded class name collisions that have plagued CSS