Implement Functional Programming Patterns in React

Functional Programming in React applies fp-ts patterns to common React state and data problems. It covers eight areas: representing state that may or may not exist with Option instead of null checks, chaining optional values safely; form validation with Either, including collecting all errors at once rather than stopping at the first one, and field-level errors for better UX; data fetching with TaskEither via a basic fetch hook, chaining dependent API calls, and running parallel API calls; the RemoteData pattern for async state, which replaces ad-hoc loading/error boolean flags with a single four-state type that makes impossible state combinations unrepresentable:

// RemoteData has exactly 4 states - no impossible combinations
type RemoteData<E, A> =
  | { _tag: 'NotAsked' }                    // Haven't started yet
  | { _tag: 'Loading' }                     // In progress
  | { _tag: 'Failure'; error: E }           // Failed
  | { _tag: 'Success'; data: A }            // Got it!

referential stability to prevent unnecessary re-renders via useMemo or the fp-ts-react-stable-hooks library; dependency injection via React Context, including how to swap in mock dependencies for testing; React 19-specific patterns using use() for promises, useActionState for forms, and useOptimistic for instant feedback; and a common-patterns cheat sheet covering rendering based on Option, rendering based on Either, safe array rendering, and conditional props.

Use this skill when applying fp-ts's Option, Either, TaskEither, or RemoteData patterns inside React components and hooks - representing optional or fallible state, handling async data fetching cleanly, or preventing re-renders caused by referential instability. It's the wrong tool if the goal is to avoid the RemoteData-style state entirely: a plain { data, loading, error } object can represent the impossible combination of loading=true with both data and error already set, which is exactly the bug class this skill exists to rule out at the type level.

Given a React state or data-fetching problem, the skill outputs a fp-ts-based hook or component pattern matched to the problem shape: Option for "may not exist," Either for "may fail validation," TaskEither for "async and may fail," and RemoteData for "async state that shouldn't be represented as separate loading/error booleans." The cheat sheet gives named rendering patterns for each: O.match or O.fold to branch on an Option (with O.getOrElse for a simple default), E.match to branch on an Either, and A.head/A.findFirst combined with O.map and O.toNullable for safely rendering the first or a specific item from an array.

Built on fp-ts's Option, Either, TaskEither, and Array modules, the fp-ts-react-stable-hooks library for referential stability, React's built-in useMemo and Context APIs for dependency injection, and React 19's use(), useActionState, and useOptimistic hooks for the newest async/form patterns.

React developers already using or adopting fp-ts who want idiomatic patterns for optional state, form validation, async data fetching, and referential stability inside components and hooks, rather than ad-hoc null checks, boolean loading flags, and manual memoization decisions.