Skip to content

Instantly share code, notes, and snippets.

Grady Kuhnline heygrady

Block or report user

Report or block heygrady

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@heygrady
heygrady / redux-module-patterns.md
Last active Aug 16, 2019
Redux module patterns: app state, view state and regional state
View redux-module-patterns.md

Redux module patterns

app state, view state and regional state

separating components and containers

and code-splitting reducers



View redux-jsonapi-resources.md

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.

View webpack-dev-middleware.md

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
heygrady / refactoring-derived-state.md
Last active Jan 17, 2019
Refactoring derived state
View refactoring-derived-state.md

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.

View binding-handlers.md

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
heygrady / redux-modules.md
Last active Feb 24, 2019
Core concepts of redux modules
View redux-modules.md

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
heygrady / render-props.md
Last active Jul 16, 2019
Avoiding HOC; Favoring render props
View render-props.md
@heygrady
heygrady / intersection-observer.md
Last active Nov 25, 2018
Lazy loading (using IntersectionObsever) in a React app
View intersection-observer.md

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

@heygrady
heygrady / rules-for-components.md
Last active Feb 15, 2019
Rules for crafting good components
View rules-for-components.md

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
heygrady / start-server.js
Last active Jan 17, 2019
create-react-app ssr dev script
View start-server.js
// @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';
You can’t perform that action at this time.