heygrady

Binding handlers

Binding specific values to events is a common occurrence in a React application. Let's kick this off with a common example. Here we have a <Button /> that calls a click handler with a specific argument: entity. There are several things wrong here.

Note: we will be refactoring this example as we go along.

1. We're binding a function in the render method
2. We're binding two props together in the child component
3. We're breaking with several established naming conventions
4. We're using a class component when a functional component will suffice

heygrady

How to refactor derived state

In our aging react code base we had been using componentWillRecieveProps for situations where we wanted to recalculate "stuff" when props change. Recent versions of react renamed this method to UNSAFE_componentWillRecieveProps for a variety of reasons. We recently went through an exercise where we tried to kill UNSAFE_componentWillRecieveProps once and for all.

The following is a contrived example of how to refactor such a component.

Step 1: How not to do it.

Here's a button component that uses UNSAFE_componentWillReceiveProps to keep its internal state in sync with the external props.

heygrady

Redux module patterns

app state, view state and regional state

separating components and containers

and code-splitting reducers

heygrady

I was hacking my custom middleware into the webpack-dev-server like this:

start.js

// start.js
// use custom serverSideRender middleware with webpack-dev-server
const serverSideRenderMiddleware = require('./ssr-middleware')

// Copy the defaultFeatures logic from webpack-dev-server. We need to hack the

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

Rules for crafting good components

Here are some good rules for a high-quality react-redux app.

We're in the process of reworking our app to make it more maintainable. In a previous meeting we discussed the general rules of thumb for writing maintainable code. Here we're going to be covering rules of thumb for writing good components.

1. Components should do one thing.
   • We use BEM as a guide.
   • A nested "block" should be a standalone component.
2. Prefer stateless functional components.

heygrady

.box {
  -moz-box-shadow: 5px 9px 5px 5px rgba(0, 0, 0, 0.75);
  -webkit-box-shadow: 5px 9px 5px 5px rgba(0, 0, 0, 0.75);
  -o-box-shadow: 5px 9px 5px 5px rgba(0, 0, 0, 0.75);
  box-shadow: 5px 9px 5px 5px rgba(0, 0, 0, 0.75);
}

heygrady

Key concepts in a react-redux application

Redux is a collection of tools and techniques for managing a centralized "store". Essentially, your application state (your data) is kept in a central place (the store) and every part of the app that needs to read from that state does so in a controlled manner. At it's core, redux is mapping functional programming styles -- familiar to Lisp programmers -- to a modern JavaScript environment.

Many of the core concepts of react and redux can be found in other application frameworks like Angular and Ember. Classical (class based) frameworks like Ember provide a "kitchen sink" style API -- a prescriptive approach. Redux preaches a functional programming style, where composition and convention are preferred. This leads to a much smaller API but leaves a lot up to the developer.

This lack of a prescriptive API is freeing, but can lead to confusion when constructing your apps. It's up to the individual developer to follow best practices for separating concerns. The good

heygrady

Redux modules

Our applications have grown organically and our current collection of actions, reducers and selectors are due for an upgrade. This document is an attempt to outline an better way to organize our redux code.

The biggest changes here are the introduction of "modules" and redux-sagas.

Core concepts

• modules — a grouping of actions, constants, reducers, etc. that all deal with the same portion of the state.
• actions — action creators

heygrady

Lazy loading (using IntersectionObsever) in a React app

The Lighthouse performance audit tool recommends lazy-loading offscreen images (and other content)

They go a step further and recommend using the new IntersectionObserver API to manage offscreen content. Of course, you need to use a polyfill to target old browsers (core-js doesn't offer a polyfill).

The documentation provided by the Lighthouse team warns against over-applying the IntersectionObserver. The have a whole section devoted to explaining why you don't want to [intersect all the things](https://developers.google.com/web/updates/2016/04/intersectiono