Advanced React

[coryhouse]

Note: I deliberately leave many of the topics below out of fundamentals.

React top level api: https://reactjs.org/docs/react-api.html

Upcoming "use" hook

Primitive for handling asynchrony.
Works like “await” inside non-async client-side components.
Wrap promises (and soon other things like context) with “use”.
If a promise passed to use isn’t resolved, “use” suspends the component’s execution by throwing an exception. The component replays when the promise resolves.
A “usable” type is a wrapper for a value. Calling “use” unwraps it.
Only for client (like most hooks).
Async server components use plain async/await.
Only non-async server components can use hooks.
Unlike other hooks, can be called conditionally. Why? Because the data lives in the promise object itself. So there’s no need to store state for “use” across updates.
Can be placed in the same spots as “await” including blocks, switch statements, and loops.
Part of the “Data fetching with Suspense” story.

UI Architect / Frontend Architect / FrontendOps /

ops - Responsibilities:

State management / Finite State Machines / Statecharts
Reusable components, scripts, styles
Design system / Style Guide (collaboration)
Dev environment (transpiling/bundling/linting...) and dev tools
Build automation
Mock APIs
Automated testing (unit/integration/visual)
App composition/slicing
Error handling
Event Modeling
Accessibility
Performance
Security
Dev tools
Dependency management
More here and here

Signs it's time to consider extracting a new component

• Duplicated JSX (extract to the same file if not reused elsewhere) - see #8 here
• Reuse
• JSX gets difficult to read
• To allow thinking about page sections in isolation (each component becomes a black box, which reduces cognitive load)
• Props list gets long
• Document different states in Storybook, create dedicated image tests with Chromatic/Percy/etc
• API calls and JSX in same component - Extracting API concerns means you can feed mock data via props
• Performance (extract an expensive portion so you can optimize its rendering)
• To keep style selectors short (whether it be BEM or CSS Modules, smaller components = smaller namespace = can use nice short names and easily navigate). If you find yourself prefixing selectors by section like this, consider extracting a component.
• To divide work between people/teams

Why prefer fewer components?

• Less jumping between files
• Minimize prop drilling and propType declaration overhead
• Shallow trees may be easier to understand than a deeply nested tree
• Every new file adds a little bloat to the bundle due to Webpack's bundling overhead

So it's a tradeoff.

Useful middle ground here: You can declare multiple components in a single file, but export only the "parent". This avoids jumping between files and provides a clear public API. If you prefer separate files, you can create a component folder and place all its child components in that folder, then use a barrel to export only the Header.

• Summary: When I place React components in separate files

Brain Teaser

Why doesn't the onSubmit fire here?

Patterns for scaling

• Decompose React components by separating view from logic, and extracting most the code out of them into custom hooks, and classes - Great post on martinfowler.com. Ask: How much code could I reuse if I switched from React to x?
• Declare global event handlers in the capture phase by appending Capture to event name. onClickCapture, onHoverCapture, etc. Example
  Useful for large apps, multiple apps in the org, or cross-cutting concerns
• "Vertical" slicing: Split app by top-level nav
• "Tiny" slices / mixed tech: Micro frontends
  • Overview on Martin Fowler
  • MFE with React and Vue
• Use context in subtrees (see below for context)
• Share component across separate teams
• Create a company framework
• Review large open source projects <- See "Code worth reading" and identify patterns used for scaling
• Centralize URL declarations

Advanced Hooks

• useReducer - Alternative to useState. Easily test in isolation. Move state logic from component to separate file. Useful to avoid having many useState declarations and multiple calls to setState in a row. Also preferable when next state depends on the previous state (though callback form of useState also helps there). Also a valid alternative to useCallback because you can pass dispatch down instead of callback funcs. Dispatch identity is stable - it doesn't change over renders.
• useCallback - Memoize a func so that children get the same reference with each render. Useful when children are expensive to render and thus need to avoid needless re-renders due to function props changing. In other words, child components that use React.memo, shouldComponentUpdate, or PureComponent to avoid re-renders benefit from having a parent that uses useCallback to avoid needlessly sending down a new func reference on each render.
  • Tip: Struggling with useCallback dependencies causing it to be reallocated? Pass arguments to the function instead so that it has no dependencies.
• useMemo - Memoize an expensive value to avoid re-calculation on every render.
• useRef - Create a reference to a DOM element or hold a value that isn't rendered
• useImperativeHandle - Combine with useRef. Use to customize the value provided by ref. Allows parent to call arbitrary functions in child. For example, focus child's component's input. demo
• useLayoutEffect - useEffect runs after render. This runs before render. Useful when you want to calculate position before rendering.
• useDebugValue - Apply to custom hooks you share in a library so they have a useful label in devTools.

Example Custom Hooks

• https://usehooks-ts.com
• https://usehooks.com/
• Validate search params via Zod
• Rehooks is a huge repo of custom hooks and beautiful-react-hooks
• useHasCamera
• useSafeState - There's a good thread here that discusses the merits of this approach. Ideally, we'd cancel the async call which would be a more direct approach. Axios supports cancellation, so that's arguably a better option. But I will admit that cancellation is a hassle compared to this, and likely not worth the extra effort.
• useIsMounted - Check if mounted. Useful to determine whether a component has mounted for use in other custom hooks. Also useful in async processes within components. Pretty handy in try/catch/finally blocks for example.
• useAutoSave - auto save when data changes
• useAlert
• usePrevious
• useIsMobile
• useMouseCoordinates - Mouse coordinate tracker
• useApiCall - Wrap API calls in a hook to encapsulate the redundancy of tracking response, loading, and error state. Enhancement: mimic the "Only one loader" behavior by incrementing a counter each time a call starts and decrementing a counter each time a call completes or errors. Share numApiCallsInProgress or an array of apiCallsInProgress with an identifier for each between hooks via context.
• useLocalStorage - Every call to setState persists to localStorage
• useAsync - for handling an async call with loading states and errors. blog post
• useForm - simple hook for handling form state and errors
• useRequiredFields - Form with uncontrolled inputs, but values are required - Codesandbox
• Note: Avoid declaring dep array for custom hooks. Expect consumers to call useCallback/useMemo if needed.
• Support both Hooks and render props via the hydra pattern
• React-async and react-query for handling async and API calls
• React Hook Form - Custom hook for forms

JSX in Depth

• Spread attributes
• Booleans, null, undefined are ignored
• Children
  • Passing props to children
  • Demo: Create Card component that displays text inside a box with an optional title. Can also show "slots" pattern.
  • Example BlueBox component created as both a slot component and a compound component
• Pass component as prop (aka slots)
• Create app Layout component - This can hold your header, footer, context provider(s), scenario selector.

Key Advanced Features

Context

• Context - For "global" data.
• How to use context effectively by Kent C Dodds
• Avoid overuse - Child composition eliminates prop drilling (or, think "slots" if multiple children). Good example of composing children from Kent
• i18n, user data, theme, auth
• It's been around since the creation of React (and used by React Router and Redux), but not stable until 16.
• Context does NOT have to be global to the whole app.
• Use context to disallow nesting a component under itself, or under another interactive element
• You can have multiple logically separated contexts in your app.
• Wrap provider and consumer to enforce certain usage and enhance performance and here
• Wrap consumer in hook for convenient consumption. useAlert example. Just import useX and you have access. No need to import context and pass it to a useContext call. And can enforce that it's being called under a provider (as shown in link above)
• Optimize your context value if perf is an issue
• Redux remains useful. Redux offers scalable unidirectional flows, decomposed state handling via dedicated reducers and actions, hot reloading, time travel, and potential performance benefits via selectors and connect's reference comparison. Though can consider react-waterfall to get most these benefits (albeit without Redux's huge ecosystem and excellent docs).
• Perf tip: As usual, avoid declaring objects in render since they're recreated on every render which causes needless rerenders. Instead, declare the object passed down via context in state. More here under "Issues with the New API". Can put methods in state too. Or, you can memoize the function
• You can require a parent provider with a simple pattern too.
• 3 ways to consume:
  • useHook (prefer)
  • Consumer via render prop / child as func
  • Static contextType (classes only, and can only consume one context this way unless you wrap the others. Bottom line, prefer useHook)
• Connected components re-render when any values passed to the provider's value prop change. So don't declare the value in render. Instead, lift it to state.
• Require context
• Updating context from the consumer - However, consider passing dispatch and using useReducer instead since that may be preferable.
• Consuming multiple contexts
• Create dedicated "store" component that holds provider
• For performance, you likely want to wrap the component directly under your context provider in React.memo or use {props.children} - This means changes to the context value will rerender only the components consuming the context instead of the entire subtree. More here. Here's a codesandbox showing how to memo children.

Refs

• Think of refs on React elements as functions that are called after the component has rendered
• Use useCallback with a ref to run some logic when the ref's target changes. useCallbackRef example)
• React docs
• Prone to abuse. Avoid - you may not need it. Can be misused to manually change the DOM.
• 3 common valid uses:
  • 1. Read and change DOM: focus, and calculate size and position.
  • 2. Hold values not used in render in func components (can use instance vars in classes).
  • 3. Forward refs to leaf nodes to support programmatically setting focus on elements. Useful for alerts, dialogs, textInputs. This way when something new appears/changes, you can programmatically focus the element.
• Detailed blog post "The Complete Guide to React Refs"
  • Refs are basically a special case of useState that doesn't trigger a re-render
  • Set its value directly (instead of using a setter) via myRef.current = 'val here'
  • Get value via .current property: myRef.current
  • 4 approaches - cheatsheet:
    • String refs (deprecated)
    • Callback refs (clunkier syntax than createRef, but can be preferable when dealing with dynamic refs - otherwise prefer createRef or useRef below)
    • createRef (Classes only - simpler syntax than callbacks)
    • useRef (Funcs only) UseRef is basically this

Other Advanced Features

• Render outside the parent's DOM via Portals - Simple example
• Capture scroll position before render using getSnapshotBeforeUpdate. snapshot is the third param passed to componentDidUpdate.
• Strict mode - Example

State

• Use instance vars for data that's not used in render
• useMutableReducer hook for immer
• Performing optimistic UI updates
• Can declare lazy initial state for useState by passing it a func. Then the initial value isn't calculated only on initial render. (Plain default values are executed on page load when the component is parsed).
• Place state as low as you can for performance. Avoids needless re-renders.
• Keep state in sync with props via getDerivedStateFromProps
• Use functional setState to get prevState - Codepen - Why? It's safe because when React encounters multiple functional setState() calls, instead of merging objects together, React queues the functions in the order they were called.
• Extract setState calls for reuse and easy testing - Declarative. Your component class no longer cares how the state updates. It simply declares the type of update it desires.
• Init state without a constructor
• Avoid state that can be calculated on demand
• Avoid mutating state - remember to clone before mutation. Mutation fights performance enhancements like sCU and PureComponent
• Deep cloning via clone-deep, LoDash merge
• Lift state
• Controllable components
• State reducer - Allow parent to augment/override the behavior of a child component by passing down a few props, or a reference to a single reducer. Simple example
• Avoid calling setState on unmounted components by cancelling any async work (use a var if only checked in useEffect. Use a ref if needs be checked outside of useEffect - see my follow up tweet Or, here's Kent's codesandbox for class components and Axios.
• Suggestion: Treat state as immutable: React lets you use whatever style of data management you want, including mutation. However, if you can use immutable data in performance-critical parts of your application it's easy to implement shouldComponentUpdate()/PureComponent to speed up your app.
  • Value equality vs Reference equality - Summary: Value equality checks on objects and arrays is expensive. Reference equality checks are cheap. For value equality, you'd have to implement it yourself or use Lodash's _.isEqual.
  • Four immutable approaches
  • [Example of the impacts of mutation with PureComponent)(https://codesandbox.io/s/mo57vnl7x9)
  • Adding element to array? Use prevState.concat(newElement).
  • Changing existing element in an array? Use map and substitute the new value while iterating.
  • Removing an element from an array? Use .filter.
  • Or just use something like Immer. Many alternatives listed in Redux docs
• Higher order event handlers / partial application

Props

• Support passing either a string or a React component. Useful for wrapping a string in an H1 by default, but allowing someone to pass an optional component in instead for more power. Use React.isValidElement to determine if a React element has been passed in on props. Note that you output the component passed on props a var, NOT as JSX. {React.isValidElement(heading) ? heading : <H1>{heading}</H1>}
• Export enum from component when there's a finite list of options for a given prop
• Use classnames to support mixing additional class with built in class
• Passing many props through many components?
  • Consider passing an object if they're related
  • Declare in parent and pass down as a child. Accepting children increases flexibility and reduces prop drilling. This pattern can also avoid needless re-renders (see "Pass component down as prop to avoid re-render" under performance below).
  • Spread props. Pass through props via destructuring:  const { roleId, locks, ...passThroughProps} = props;
• Declare shapes
• Centralize propTypes
• Avoid blindly creating defaultProps for all props. This leads to components that fail to warn you about missing props, and instead, do nothing.
• Props default to true
• Create a combine function to blend a func passed in on props with the components's built in behavior
• Require all props at first
• Declare propTypes and defaultProps via statics
• Destructure props in functional component args, or top of render in class components
  • Other advanced destructuring examples
• Destructure and optionally alias prop-types import to shorten propTypes declarations
• Easily generate propTypes from JSON via transform.now.sh
• Spread attributes - Example
• Standardize event handler naming
• PropTypes vs TypeScript and Flow
• Pass props to children using cloneElement or renderProps

Performance

• See more in dedicated issue: Performance Checklist #77
• 6 techniques for managing large datasets in React
• 2020 Comparison of React perf vs competition
• Many ideas on React docs
• Use react-adaptive-hooks to implement progressive enhancement for devices with different network, CPU, cores, and memory.
• Pass component down as prop to avoid re-render. Here's the slow version that re-renders. More in Ken's blog post. More complex example
• React bails out of rendering children if the children haven't changed, so no sCU, memo needed.
• Store data in localStorage to allow offline use and speed subsequent re-renders
• Use memo, ref, or pass a func to useState if the initial value calls an expensive func, otherwise, it will be calculated on each render.
• Extract child components for expensive portions (optimize when they render via React.memo).
• Before you reach for memo
• Avoid declaring objects in render. It creates a new object on every render. This includes when passing objects via props.
  • Use React.memo to avoid needless re-renders Demo
    • Can use React.memo with context too, but need to "lift" context consumer to parent. Remember, with context, all children of provider rerender when the provider component renders.
    • 3 ways to memo context
  • Could I create one instance per page instead of one per row (e.g. Avoid tooltip per row on large table, or dialog per row on large table. Instead, create one and populate dynamically based on a row click/hover)
  • Remove one item at a time from a row/feature until it renders fast to help find the culprit.
• Demo of React.memo and useCallback. Also, check out scheduling performance example in performance-tuning folder in this repo
• See static rendering under Server Render below
• Change related state at the same time to avoid redundant renders
• Pass primitives (strings, numbers...) to child components to assist with diffing. Avoid passing arrow funcs and objects on props when performance is a concern since it leads to needless re-renders of child components.
• React Lazy and Suspense, or consider Loadable components if you want server-side support, library lazy loading, and full dynamic imports.
• Suspense for data fetching - Repo here. Can also use react-query in suspense mode or fetch-suspense (much less popular) or [react-fetching-library](https://codesandbox.io/s/4202lm924w, https://github.com/marcin-piela/react-fetching-library). Also see https://www.robinwieruch.de/react-hooks-fetch-data/, https://resthooks.io/.

Old alternatives to React.lazy:

• react-loadable
• react-lazyload
• react-lazy-load-fadein
• react-content-loader
• react-ideal-image
• react-progressive-loader (Load images and components when scrolled into view)
• Even more options listed here, some that support server rendering
• Cache React event listeners
• Use plop or hygen to make lazy loading components easy. react-boilerplate example
• Note cost:
  • Trading static for dynamic, so reduced safety and autocomplete support.
  • Adds decision fatigue.
  • Adds latency.
  • Adds complexity.
  • Easy to get wrong by accidentally statically importing the component elsewhere. Consider writing tests that assert lazy loaded components aren't part of bundle. But that's extra work too.
• Lazy load libraries via webpack dynamic imports
• why-did-you-render - inspired by Why did you update - Find unnecessary renders
• Consider shouldComponentUpdate/PureComponent. Why? When you call setState, React will compare the old React elements to a new set of React elements (this is called reconciliation) and then use that information to update the real DOM elements. Sometimes that can get slow if you’ve got a lot of elements to check (like a big table, list, or SVG). But only use after measuring result. Here's how to measure. Don’t imagine “I bet that code is slow”. Write your code naturally. If there are performance problems, fix them. Do not PureComponent all the things. "I added PureRenderMixin to every component. My app got slower 🤔." - Ryan Florence Why? A component does one diff. A pureComponent does one or two diffs (props and state in shouldComponentUpdate, and then the normal element diff). So if a component usually changes when there’s an update, then a PureComponent will be doing two diffs instead of just one. This means it’s going to be slower usually but faster occasionally. So if most of your components change most of the time, your app will get slower by using PureComponent everywhere because you're doing two diffs instead of one.
• Binding
  • Binding Patterns - 5 Ways to handle the this keyword
  • Avoid bind in render
  • Pluck data from event by querying form elements via event.target.elements.fieldName.value - See SearchInput here. Or extract child components to avoid binding
  • Prefer constructor bind if there will be a massive number of instances. (otherwise, suggest class fields for convenience)
• Use ESI to reduce DB calls by selectively caching pieces of the page via an HOC
• Call setState with null to avoid re-render when the relevant state hasn't actually changed. (useful when someone clicked a button that fires a setState call, but no state is actually changed.
• Prerender with react-snap or with react-snapshot
• Use selectors for Redux
• Normalize your Redux store
• Structure your Redux store by key for fast access
• Consider Preact, Inferno
• List of perf related blog posts
• 21 React Related Perf Tweaks

Forms

I recommend plain React. Here's a poll. But, many options. A few popular options:

• Formik
• React Final Form
• react-jsonschema-form

Maintainability

• Cancelling async requests
  • Simple Hooks example or funny, yet clear alternative
  • Use date / promise comparison, or AbortController. My abortcontroller example
• Use Barrel pattern to shorten imports
• Centralized form change handers
• When to consider creating a new component
  • To support reuse of a portion
  • Mixing complex logic and presentation
  • To avoid re-rendering an expensive portion
  • Repetition in JSX - Just create a func inside a component instead if separate component isn't needed
  • Displaying unrelated data
  • Handling unrelated logic
• Folder structure
  • Component folder pattern
  • Organize component folders to mimic routing path. Place reusable components in /UI. Don't repeat the path name in the component's name, but when importing, alias the default to reflect the import path. Example: import UserList from './User/List.js';
  • The "brick" pattern at eBay - Folder structure. All the things in a brick
• Centralized change handler
• Transform HTML to JSX using transform.now.sh
• Separate logic and layout
• Container vs Presentation components (aka smart vs dumb)
  • Use Stateless components for dumb components?
    • The good parts
    • The bad parts
• Conditionals in render - Many options
  • Ternary
  • Logical &&, || in render - Can combine func call with && too
  • Multiple return/return early
• Component composition
  • props.children
  • Specialization
  • Branch pattern
• Higher order components
  • Manually set the displayName for clearer debugging in the console
  • Create HOC from render prop component
• Render props / function as child
  • Compose render props together elegantly
• Compound components
  • Simple example that uses IDs
  • Opinionated example - can only use string for label
  • Advanced example that uses cloneElement to avoid IDs, but at expense of more wrapper elements and implementation complexity
  • Ryan Florence's composition examples with 4 different levels of complexity
• Formatting/styling components
• Integrate React into an existing app
• The 8 Key React Component Decisions
• Common mistakes
• More common mistakes from Elijah Manor

Debugging

• debugger keyword
• Use react-dev-tools
• console.log accepts multiple params
  • Use with concise arrow syntax in functional components that use parens for render
  • Easily format output to the console
  • console.table
  • console.assert
• Use logical or to force conditionals to true (helpful to force ongoing display of loaders that go away quickly)
• JSX IIFE Debugger pattern

Server Rendering

• Render to static files
• Static site generators like Gatsby, Next, etc
• Prerender.io
• Comprehensive blog post (summary: It's complicated)
• Rogue
• Example repo

Deployment

• If users leave their tab open for days/weeks, they may request an old file when they click a link. Avoid users getting errors by requesting an old file that's no longer deployed by including the site version in a cookie. Use that to say "A new version of the site is available. Click OK to reload the site." as suggested by Rich Harris.

More?

• Show and tell! What patterns have you found useful?