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

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

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.

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

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

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:

begin fetching
receive data or receive error (or bail when cancelled)

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.

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

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

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.

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

	// @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';