"This guide is a living compendium documenting the most important patterns and recipes on how to use React (and its Ecosystem) in a functional style using TypeScript. It will help you make your code completely type-safe while focusing on inferring the types from implementation so there is less noise coming from excessive type annotations and it's easier to write and maintain correct types in the long run."
⭐ Found it useful? Want more updates? Show your support by giving a ⭐
🎉 Now updated to support TypeScript v3.4 🎉
Goals
- Complete type safety (with
--strictflag) without losing type information downstream through all the layers of our application (e.g. no type assertions or hacking withanytype) - Make type annotations concise by eliminating redundancy in types using advanced TypeScript Language features like Type Inference and Control flow analysis
- Reduce repetition and complexity of types with TypeScript focused complementary libraries
React, Redux, Typescript Ecosystem
- typesafe-actions - Typesafe utilities for "action-creators" in Redux / Flux Architecture
- utility-types - Collection of generic types for TypeScript, complementing built-in mapped types and aliases - think lodash for reusable types.
- react-redux-typescript-scripts - dev-tools configuration files shared between projects based on this guide
Codesandbox links
- Reference Todo-App implementation using React, Redux, Typescript Guide: Link
Playground Project
You should check out Playground Project located in the /playground folder. It is a source of all the code examples found in the guide. They are all tested with the most recent version of TypeScript and 3rd party type-definitions (like @types/react or @types/react-redux) to ensure the examples are up-to-date and not broken with updated definitions. It's based on create-react-app --typescript.
Playground project was created so that you can simply clone the repository locally and immediately play around with all the component patterns found in the guide. It will help you to learn all the examples from this guide in a real project environment without the need to create complicated environment setup by yourself.
We are open for contributions. If you're planning to contribute please make sure to read the contributing guide: CONTRIBUTING.md
This is an independent open-source project created by people investing their free time for the benefit of our community.
If you are using it please consider donating as this will guarantee the project will be updated and maintained in the long run.
Issues can be funded by anyone interested in them being resolved. Reward will be transparently distributed to the contributor handling the task through the IssueHunt platform.
🌟 - New or updated section
- Installation
- React - Type-Definitions Cheatsheet
- React - Typing Patterns
- Redux - Typing Patterns
- Configuration & Dev Tools
- Recipes
- Tutorials & Articles
- Contributors
npm i -D @types/react @types/react-dom @types/react-redux
"react" - @types/react
"react-dom" - @types/react-dom
"redux" - (types included with npm package)*
"react-redux" - @types/react-redux
*NB: Guide is based on types for Redux >= v4.x.x. To make it work with Redux v3.x.x please refer to this config)
Type representing a functional component
const MyComponent: React.FC<Props> = ...Type representing a class component
class MyComponent extends React.Component<Props, State> { ...Type representing union of (React.FC | React.Component) - used in HOC
const withState = <P extends WrappedComponentProps>(
WrappedComponent: React.ComponentType<P>,
) => { ...Gets Props type of a specified component XXX (WARNING: does not work with statically declared default props and generic props)
type MyComponentProps = React.ComponentProps<typeof MyComponent>;Type representing a concept of React Element - representation of a native DOM component (e.g. <div />), or a user-defined composite component (e.g. <MyComponent />)
const elementOnly: React.ReactElement = <div /> || <MyComponent />;Type representing any possible type of React node (basically ReactElement (including Fragments and Portals) + primitive JS types)
const elementOrPrimitive: React.ReactNode = 'string' || 0 || false || null || undefined || <div /> || <MyComponent />;
const Component = ({ children: React.ReactNode }) => ...Type representing style object in JSX - for css-in-js styles
const styles: React.CSSProperties = { flexDirection: 'row', ...
const element = <div style={styles} ...Type representing Props of specified HTML Element - for extending HTML Elements
const Input: React.FC<Props & React.HTMLProps<HTMLInputElement>> = props => { ... }
<Input about={...} accept={...} alt={...} ... />Type representing generic event handler - for declaring event handlers
const handleChange: React.ReactEventHandler<HTMLInputElement> = (ev) => { ... }
<input onChange={handleChange} ... />Type representing more specific event handler. Some common event examples: ChangeEvent, FormEvent, FocusEvent, KeyboardEvent, MouseEvent, DragEvent, PointerEvent, WheelEvent, TouchEvent.
const handleChange = (ev: React.MouseEvent<HTMLDivElement>) => { ... }
<div onMouseMove={handleChange} ... />::codeblock='playground/src/components/fc-counter.tsx'::
- spread attributes link
::codeblock='playground/src/components/fc-spread-attributes.tsx'::
::codeblock='playground/src/components/class-counter.tsx'::
::codeblock='playground/src/components/class-counter-with-default-props.tsx'::
- easily create typed component variations and reuse common logic
- common use case is a generic list components
::codeblock='playground/src/components/generic-list.tsx'::
simple component using children as a render prop
::codeblock='playground/src/components/name-provider.tsx'::
Mousecomponent found in Render Props React Docs
::codeblock='playground/src/components/mouse-provider.tsx'::
Adds state to a stateless counter
::codeblock='playground/src/hoc/with-state.tsx':: ::expander='playground/src/hoc/with-state.usage.tsx'::
Adds error handling using componentDidCatch to any component
::codeblock='playground/src/hoc/with-error-boundary.tsx':: ::expander='playground/src/hoc/with-error-boundary.usage.tsx'::
::codeblock='playground/src/connected/fc-counter-connected.tsx':: ::expander='playground/src/connected/fc-counter-connected.usage.tsx'::
::codeblock='playground/src/connected/fc-counter-connected-own-props.tsx':: ::expander='playground/src/connected/fc-counter-connected-own-props.usage.tsx'::
::codeblock='playground/src/connected/fc-counter-connected-bind-action-creators.tsx':: ::expander='playground/src/connected/fc-counter-connected-bind-action-creators.usage.tsx'::
::codeblock='playground/src/context/theme-context.ts'::
::codeblock='playground/src/context/theme-provider.tsx'::
::codeblock='playground/src/context/theme-consumer.tsx'::
::codeblock='playground/src/context/theme-consumer-class.tsx'::
::codeblock='playground/src/hooks/use-state.tsx'::
Hook for state management like Redux in a function component.
::codeblock='playground/src/hooks/use-reducer.tsx'::
::codeblock='playground/src/hooks/use-theme-context.tsx'::
Can be imported in connected components to provide type-safety to Redux connect function
Can be imported in various layers receiving or sending redux actions like: reducers, sagas or redux-observables epics
::codeblock='playground/src/store/types.d.ts'::
When creating a store instance we don't need to provide any additional types. It will set-up a type-safe Store instance using type inference.
The resulting store instance methods like
getStateordispatchwill be type checked and will expose all type errors
::codeblock='playground/src/store/index.ts'::
We'll be using a battle-tested library
that'll help retain complete type soundness and simplify maintenace of types in Redux Architectures
typesafe-actions
You can find more real-world examples and in-depth tutorial in: Typesafe-Actions - Tutorial!
A solution below is using a simple factory function to automate the creation of type-safe action creators. The goal is to decrease maintenance effort and reduce code repetition of type annotations for actions and creators. The result is completely typesafe action-creators and their actions.
::codeblock='playground/src/features/counters/actions.ts':: ::expander='playground/src/features/counters/actions.usage.ts'::
Declare reducer State type with readonly modifier to get compile time immutability
export type State = {
readonly counter: number;
readonly todos: ReadonlyArray<string>;
};Readonly modifier allow initialization, but will not allow reassignment by highlighting compiler errors
export const initialState: State = {
counter: 0,
}; // OK
initialState.counter = 3; // TS Error: cannot be mutatedIt's great for Arrays in JS because it will error when using mutator methods like (push, pop, splice, ...), but it'll still allow immutable methods like (concat, map, slice,...).
state.todos.push('Learn about tagged union types') // TS Error: Property 'push' does not exist on type 'ReadonlyArray<string>'
const newTodos = state.todos.concat('Learn about tagged union types') // OKThis means that the readonly modifier doesn't propagate immutability down the nested structure of objects. You'll need to mark each property on each level explicitly.
TIP: use
ReadonlyorReadonlyArrayMapped types
export type State = Readonly<{
counterPairs: ReadonlyArray<Readonly<{
immutableCounter1: number,
immutableCounter2: number,
}>>,
}>;
state.counterPairs[0] = { immutableCounter1: 1, immutableCounter2: 1 }; // TS Error: cannot be mutated
state.counterPairs[0].immutableCounter1 = 1; // TS Error: cannot be mutated
state.counterPairs[0].immutableCounter2 = 1; // TS Error: cannot be mutatedTo fix this we can use DeepReadonly type (available from utility-types).
import { DeepReadonly } from 'utility-types';
export type State = DeepReadonly<{
containerObject: {
innerValue: number,
numbers: number[],
}
}>;
state.containerObject = { innerValue: 1 }; // TS Error: cannot be mutated
state.containerObject.innerValue = 1; // TS Error: cannot be mutated
state.containerObject.numbers.push(1); // TS Error: cannot use mutator methodsto understand following section make sure to learn about Type Inference, Control flow analysis and Tagged union types
::codeblock='playground/src/features/todos/reducer.ts'::
Notice we are not required to use any generic type parameter in the API. Try to compare it with regular reducer as they are equivalent.
::codeblock='playground/src/features/todos/reducer-ta.ts'::
::codeblock='playground/src/features/todos/reducer.spec.ts'::
::codeblock='playground/src/features/todos/epics.ts'::
::codeblock='playground/src/features/todos/epics.spec.ts'::
::codeblock='playground/src/features/todos/selectors.ts'::
NOTE: Below you'll find only a short explanation of concepts behind typing connect. For more real-world examples please check Redux Connected Components section.
import MyTypes from 'MyTypes';
import { bindActionCreators, Dispatch, ActionCreatorsMapObject } from 'redux';
import { connect } from 'react-redux';
import { countersActions } from '../features/counters';
import { FCCounter } from '../components';
// Type annotation for "state" argument is mandatory to check
// the correct shape of state object and injected props you can also
// extend connected component Props interface by annotating `ownProps` argument
const mapStateToProps = (state: MyTypes.RootState, ownProps: FCCounterProps) => ({
count: state.counters.reduxCounter,
});
// "dispatch" argument needs an annotation to check the correct shape
// of an action object when using dispatch function
const mapDispatchToProps = (dispatch: Dispatch<MyTypes.RootAction>) =>
bindActionCreators({
onIncrement: countersActions.increment,
}, dispatch);
// shorter alternative is to use an object instead of mapDispatchToProps function
const dispatchToProps = {
onIncrement: countersActions.increment,
};
// Notice we don't need to pass any generic type parameters to neither
// the connect function below nor map functions declared above
// because type inference will infer types from arguments annotations automatically
// This is much cleaner and idiomatic approach
export const FCCounterConnected =
connect(mapStateToProps, mapDispatchToProps)(FCCounter);
// You can add extra layer of validation of your action creators
// by using bindActionCreators generic type parameter and RootAction type
const mapDispatchToProps = (dispatch: Dispatch<MyTypes.RootAction>) =>
bindActionCreators<ActionCreatorsMapObject<Types.RootAction>>({
invalidActionCreator: () => 1, // Error: Type 'number' is not assignable to type '{ type: "todos/ADD"; payload: Todo; } | { ... }
}, dispatch);NOTE: When using thunk action creators you need to use bindActionCreators. Only this way you can get corrected dispatch props type signature like below.
WARNING: As of now (Apr 2019) bindActionCreators signature of the latest redux-thunk release will not work as below, you need to use updated type definitions that you can find here /playground/typings/redux-thunk/index.d.ts and then add paths overload in your tsconfig like this: "paths":{"redux-thunk":["typings/redux-thunk"]}.
const thunkAsyncAction = () => async (dispatch: Dispatch): Promise<void> => {
// dispatch actions, return Promise, etc.
}
const mapDispatchToProps = (dispatch: Dispatch<Types.RootAction>) =>
bindActionCreators(
{
thunkAsyncAction,
},
dispatch
);
type DispatchProps = ReturnType<typeof mapDispatchToProps>;
// { thunkAsyncAction: () => Promise<void>; }
/* Without "bindActionCreators" fix signature will be the same as the original "unbound" thunk function: */
// { thunkAsyncAction: () => (dispatch: Dispatch<AnyAction>) => Promise<void>; }Common TS-related npm scripts shared across projects
"prettier": "prettier --list-different 'src/**/*.ts' || (echo '\nPlease fix code formatting by running:\nnpm run prettier:fix\n'; exit 1)",
"prettier:fix": "prettier --write 'src/**/*.ts'",
"lint": "tslint -p ./",
"tsc": "tsc -p ./ --noEmit",
"tsc:watch": "tsc -p ./ --noEmit -w",
"test": "jest --config jest.config.json",
"test:watch": "jest --config jest.config.json --watch",
"test:update": "jest --config jest.config.json -u"
"ci-check": "npm run prettier && npm run lint && npm run tsc && npm run test",
We have our own recommended tsconfig.json that you can easily add to your project thanks to react-redux-typescript-scripts package.
::expander='playground/tsconfig.json'::
https://www.npmjs.com/package/tslib
This library will cut down on your bundle size, thanks to using external runtime helpers instead of adding them per each file.
Installation
npm i tslib
Then add this to your tsconfig.json:
"compilerOptions": {
"importHelpers": true
}https://palantir.github.io/tslint/
Installation
npm i -D tslint
For React project you should add additional
reactspecific rules:npm i -D tslint-reacthttps://github.com/palantir/tslint-react
We have our own recommended config that you can easily add to your project thanks to react-redux-typescript-scripts package.
::expander='playground/tslint.json'::
https://eslint.org/
https://typescript-eslint.io
Installation
npm i -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin
We have our own recommended config that will automatically add a parser & plugin for TypeScript thanks to react-redux-typescript-scripts package.
::expander='playground/.eslintrc'::
Installation
npm i -D jest ts-jest @types/jest
::expander='configs/jest.config.json'::
::expander='configs/jest.stubs.js'::
No. With TypeScript, using PropTypes is an unnecessary overhead. When declaring Props and State interfaces, you will get complete intellisense and design-time safety with static type checking. This way you'll be safe from runtime errors and you will save a lot of time on debugging. Additional benefit is an elegant and standardized method of documenting your component public API in the source code.
From practical side, using interface declaration will create an identity (interface name) in compiler errors, on the contrary type aliases doesn't create an identity and will be unwinded to show all the properties and nested types it consists of.
Although I prefer to use type most of the time there are some places this can become too noisy when reading compiler errors and that's why I like to leverage this distinction to hide some of not so important type details in errors using interfaces identity.
Related ts-lint rule: https://palantir.github.io/tslint/rules/interface-over-type-literal/
A common flexible solution is to use module folder pattern, because you can leverage both named and default import when you see fit.
With this solution you'll achieve better encapsulation and be able to safely refactor internal naming and folders structure without breaking your consumer code:
// 1. create your component files (`select.tsx`) using default export in some folder:
// components/select.tsx
const Select: React.FC<Props> = (props) => {
...
export default Select;
// 2. in this folder create an `index.ts` file that will re-export components with named exports:
// components/index.ts
export { default as Select } from './select';
...
// 3. now you can import your components in both ways, with named export (better encapsulation) or using default export (internal access):
// containers/container.tsx
import { Select } from '@src/components';
or
import Select from '@src/components/select';
...Prefered modern syntax is to use class Property Initializers
class ClassCounterWithInitialCount extends React.Component<Props, State> {
// default props using Property Initializers
static defaultProps: DefaultProps = {
className: 'default-class',
initialCount: 0,
};
// initial state using Property Initializers
state: State = {
count: this.props.initialCount,
};
...
}Prefered modern syntax is to use Class Fields with arrow functions
class ClassCounter extends React.Component<Props, State> {
// handlers using Class Fields with arrow functions
handleIncrement = () => {
this.setState({ count: this.state.count + 1 });
};
...
}For type augmentation imports should stay outside of module declaration.
import { Operator } from 'rxjs/Operator';
import { Observable } from 'rxjs/Observable';
declare module 'rxjs/Subject' {
interface Subject<T> {
lift<R>(operator: Operator<T, R>): Observable<R>;
}
}When creating 3rd party type-definitions all the imports should be kept inside the module declaration, otherwise it will be treated as augmentation and show error
declare module "react-custom-scrollbars" {
import * as React from "react";
export interface positionValues {
...if you cannot find types for a third-party module you can provide your own types or disable type-checking for this module using Shorthand Ambient Modules
::codeblock='playground/typings/modules.d.ts'::
If you want to use an alternative (customized) type-definitions for some npm module (that usually comes with it's own type-definitions), you can do it by adding an override in paths compiler option.
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"redux": ["typings/redux"], // use an alternative type-definitions instead of the included one
...
},
...,
}
}Strategies to fix issues coming from external type-definitions files (*.d.ts)
// added missing autoFocus Prop on Input component in "[email protected]" npm package
declare module '../node_modules/antd/lib/input/Input' {
export interface InputProps {
autoFocus?: boolean;
}
}// fixed broken public type-definitions in "[email protected]" npm package
import { Operator } from 'rxjs/Operator';
import { Observable } from 'rxjs/Observable';
declare module 'rxjs/Subject' {
interface Subject<T> {
lift<R>(operator: Operator<T, R>): Observable<R>;
}
}More advanced scenarios for working with vendor type-definitions can be found here Official TypeScript Docs
Curated list of relevant in-depth tutorials
Higher-Order Components:
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!
MIT License
Copyright (c) 2017 Piotr Witek [email protected] (http://piotrwitek.github.io)