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

heygrady

Avoiding HOC; Favoring render props

The React community is moving away from HOC (higher order components) in favor of render prop components (RPC). For the most part, HOC and render prop components solve the same problem. However, render prop components provide are gaining popularity because they are more declarative and flexible than an HOC.

Read more:

• Use a render prop
• Breaking up with HOC
• HOC vs. render props
• React HOC docs
• React render props docs

heygrady

2.0.0@mygemset

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

(function(window, document, undefined){
"use strict";

// create a test element
var testElem = document.createElement('test'),
    docElement = document.documentElement,
    defaultView = document.defaultView,
    getComputedStyle = defaultView && defaultView.getComputedStyle,
    computedValueBug,
    runit = /^(-?[\d+\.\-]+)([a-z]+|%)$/i,

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

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

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 JSONAPI Resources

Ideas:

1. Store resources in redux following the JSONAPI resource spec.
2. Provide actions and thunks for managing resources similar to what Ember Data Models support.

Let's take an example of a building that has floorplans.