Reference

Lint rules

The level is the default. uf lint --rules prints the level each rule runs at in your project, and whether a fix applies. Rules marked needs type inference are listed but do not run yet: uf reports them as unavailable, and their examples show what they will check.

Flow

Flow's own lints and the parse check, configured beside uf's rules.

React

Component and hook syntax, JSX shape, and memoization the compiler already does.

React Compiler

The official React Compiler's diagnostics, one rule per category.

Accessibility

JSX that a screen reader, a keyboard or a switch cannot use.

Markup

HTML the browser's parser would rewrite or ignore.

Imports

The static import graph: cycles, undeclared packages and paths.

Server

Server components, server actions and the client boundary.

Router

File-system routes the router would not serve.

Security

Known vulnerability classes kept out of the code.

Fetch

The instrumented fetch the toolchain is built around.

React Native

Platform-specific modules.

Vite

@uniflowed/vite configuration.

package.json

Manifests that shell out instead of declaring tasks.

House rules

Whitespace, tasks and the suppression comments themselves.

Every rule, with examples

flow/ambiguous-object-type

Default: off. Object type annotations must state exactness explicitly.

An object type written as { id: string } means exact or inexact depending on the project's exact_by_default setting, so the same annotation reads differently in two projects. Say which one you mean: {| id: string |} for exact, or { id: string, ... } for inexact. Off by default, because Modern Flow makes objects exact by default.

Bad

// @flow
export type Props = { id: string };

uf lint reports:

app/example.js:2:21 object type is neither exact (`{| |}`) nor explicitly inexact (`...`)

Good

// @flow
export type Exact = {| id: string |};
export type Open = { id: string, ... };

flow/default-import-access

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Do not read named exports off a default import.

Reading a named export off a default import, as in React.useState where React is the default export, only works when the default export happens to be an object that also carries that property. Import the named export itself.

Bad

// @flow
import React from "react";

export hook useCount(): number {
  const [count] = React.useState(0);
  return count;
}

Good

// @flow
import { useState } from "react";

export hook useCount(): number {
  const [count] = useState(0);
  return count;
}

flow/deprecated-type

Default: error. The bool type alias is deprecated; write boolean.

bool is a deprecated alias Flow still accepts. Write boolean, the name Flow and every other type system use.

Bad

// @flow
export type Toggle = { readonly on: bool };

uf lint reports:

app/example.js:2:37 the `bool` type alias is deprecated; write `boolean`

Good

// @flow
export type Toggle = { readonly on: boolean };

flow/export-renamed-default

Default: warn. Avoid export { value as default }; use an explicit default export.

export { value as default } makes a default export that is easy to miss when reading the module's exports. Write export default where the value is declared.

Bad

// @flow
const page = { title: "Home" };
export { page as default };

uf lint reports:

app/example.js:3:15 renaming an export to `default` hides the real name; export it directly

Good

// @flow
const page = { title: "Home" };
export default page;

flow/internal-type

Default: error. Do not reference Flow's internal types directly.

Names like React$Node and $TEMPORARY$object are internal to Flow's library definitions and can change between Flow releases without notice. Import the public type instead.

Bad

// @flow
export type Slot = React$Node;

uf lint reports:

app/example.js:2:20 this is a Flow-internal type; use the public equivalent

Good

// @flow
import type { Node } from "react";

export type Slot = Node;

flow/invalid-import-star-use

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Namespace imports may only be used for member access.

A namespace import (import * as ns) is a module object that Flow can only check when you read members off it. Passing the namespace around as a value loses those checks.

Bad

// @flow
import * as math from "./math.js";

export const helpers = math;

Good

// @flow
import * as math from "./math.js";

export const total: number = math.sum([1, 2, 3]);

flow/invalid-this-arg

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Do not rebind a method to an incompatible receiver.

Calling a method through .call, .apply or .bind with a receiver of the wrong type runs the method with a this it was never written for.

Bad

// @flow
class Counter {
  count: number = 0;
  increment(): void {
    this.count += 1;
  }
}

const counter = new Counter();
counter.increment.call({ total: 0 });

Good

// @flow
class Counter {
  count: number = 0;
  increment(): void {
    this.count += 1;
  }
}

const counter = new Counter();
counter.increment.call(counter);

flow/libdef-override

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Library definitions must not override built-in declarations.

A library definition that redeclares something Flow's built-in libraries already define, such as Array or Promise, silently replaces the real type for the whole project.

Bad

// @flow
// flow-typed/overrides.js
declare class Promise<+R> {
  then(onFulfill: (value: R) => mixed): Promise<mixed>;
}

Good

// @flow
// flow-typed/my-sdk.js
declare module "my-sdk" {
  declare export function connect(url: string): Promise<void>;
}

flow/mixed-import-and-require

Default: error. Do not mix import and require in one module.

A module that uses both import and require runs through two module systems, with different loading order and interop rules. Keep an ES module on import. When a CommonJS-only file has to be loaded, use the createRequire bridge that Node documents.

Bad

// @flow
import { readFile } from "node:fs/promises";
const path = require("node:path");

export async function read(name: string): Promise<string> {
  return readFile(path.join("data", name), "utf8");
}

uf lint reports:

app/example.js:3:14 this module already uses `import`; do not mix in `require`

Good

// @flow
import { readFile } from "node:fs/promises";
import path from "node:path";

export async function read(name: string): Promise<string> {
  return readFile(path.join("data", name), "utf8");
}

flow/nested-component

Default: error. Do not declare a component inside another component or hook.

A component declared inside another component or hook is a new component on every render, so React unmounts and remounts it each time and its state is lost. Declare components at the top level of a module.

Bad

// @flow
export component List(items: $ReadOnlyArray<string>) {
  component Row(label: string) {
    return <li>{label}</li>;
  }
  return <ul>{items.map((item) => <Row key={item} label={item} />)}</ul>;
}

uf lint reports:

app/example.js:3:3 declare this component at module scope; nesting it remounts its subtree every render

Good

// @flow
component Row(label: string) {
  return <li>{label}</li>;
}

export component List(items: $ReadOnlyArray<string>) {
  return <ul>{items.map((item) => <Row key={item} label={item} />)}</ul>;
}

flow/nested-hook

Default: error. Do not declare a hook inside another component or hook.

A hook declared inside a component or another hook is a new function on every render, and the Rules of Hooks cannot be checked across it. Declare hooks at the top level of a module.

Bad

// @flow
import { useState } from "react";

export component Counter() {
  hook useCount(): number {
    const [count] = useState(0);
    return count;
  }
  return <output>{useCount()}</output>;
}

uf lint reports:

app/example.js:5:3 declare this hook at module scope; a nested hook gets a new identity every render

Good

// @flow
import { useState } from "react";

hook useCount(): number {
  const [count] = useState(0);
  return count;
}

export component Counter() {
  return <output>{useCount()}</output>;
}

flow/non-const-var-export

Default: error. Exported bindings must be const.

An exported let or var can be reassigned by the module after other modules have imported it, and the importers see the change through a live binding. Export a const, and export a function when callers need to change the value.

Bad

// @flow
export let count = 0;

uf lint reports:

app/example.js:2:8 exported bindings must be `const`; a mutable export is a live binding

Good

// @flow
let count = 0;

export const initial = 0;

export function increment(): number {
  count += 1;
  return count;
}

flow/nonstrict-import

Default: warn · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. @flow strict modules may only import other strict modules.

A @flow strict module promises that everything it touches is checked strictly. Importing a module that is not strict breaks that promise at the import.

Bad

// @flow strict
import { format } from "./legacy-format.js"; // a `@flow` module, not strict

export const label: string = format(3);

Good

// @flow strict
import { format } from "./format.js"; // also `@flow strict`

export const label: string = format(3);

flow/react-intrinsic-overlap

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. A value used as a component must not overlap a JSX intrinsic.

A value used as a JSX component whose type overlaps an intrinsic element's name, such as a string "div", renders a DOM element where you meant a component. Give JSX a component, not a string that may be a tag.

Bad

// @flow
export component Box(as: string) {
  const Tag = as;
  return <Tag />;
}

Good

// @flow
export component Box(as: "section" | "article") {
  return as === "section" ? <section /> : <article />;
}

flow/require-explicit-enum-checks

Default: warn · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Compare Flow enum values explicitly instead of testing truthiness.

Testing a Flow enum value for truthiness hides which members you meant, and a member added later passes silently. Compare against the members explicitly.

Bad

// @flow
enum Status {
  Active,
  Paused,
}

export function isOn(status: ?Status): boolean {
  return status ? true : false;
}

Good

// @flow
enum Status {
  Active,
  Paused,
}

export function isOn(status: ?Status): boolean {
  return status === Status.Active;
}

flow/require-explicit-enum-switch-cases

Default: warn · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. List Flow enum switch cases explicitly instead of relying on default.

A default branch in a switch over a Flow enum catches members added later without anyone deciding what they should do. List every member, so that adding one is a type error until it is handled. match gives the same exhaustiveness check.

Bad

// @flow
enum Status {
  Active,
  Paused,
  Closed,
}

export function label(status: Status): string {
  switch (status) {
    case Status.Active:
      return "active";
    default:
      return "inactive";
  }
}

Good

// @flow
enum Status {
  Active,
  Paused,
  Closed,
}

export function label(status: Status): string {
  return match (status) {
    Status.Active => "active",
    Status.Paused => "paused",
    Status.Closed => "closed",
  };
}

flow/sketchy-null

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Existence check on a value that may be both nullish and falsey.

An existence check such as if (value) on a ?number is false both when the value is missing and when it is 0, and the code usually meant only one of them. Compare with null explicitly. This rule covers every such type; the sketchy-null-* rules name one type each.

Bad

// @flow
export function describe(value: ?number): string {
  if (value) {
    return "set";
  }
  return "missing";
}

Good

// @flow
export function describe(value: ?number): string {
  if (value != null) {
    return "set";
  }
  return "missing";
}

flow/sketchy-null-bigint

Default: off · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Existence check on a ?bigint (covered by flow/sketchy-null).

An existence check such as if (value) on a ?bigint is false both when the value is missing and when it is 0n, and the code usually meant only one of them. Compare with null explicitly. Off by default: flow/sketchy-null covers it.

Bad

// @flow
export function describe(value: ?bigint): string {
  if (value) {
    return "set";
  }
  return "missing";
}

Good

// @flow
export function describe(value: ?bigint): string {
  if (value != null) {
    return "set";
  }
  return "missing";
}

flow/sketchy-null-bool

Default: off · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Existence check on a ?boolean (covered by flow/sketchy-null).

An existence check such as if (value) on a ?boolean is false both when the value is missing and when it is false, and the code usually meant only one of them. Compare with null explicitly. Off by default: flow/sketchy-null covers it.

Bad

// @flow
export function describe(value: ?boolean): string {
  if (value) {
    return "set";
  }
  return "missing";
}

Good

// @flow
export function describe(value: ?boolean): string {
  if (value != null) {
    return "set";
  }
  return "missing";
}

flow/sketchy-null-mixed

Default: off · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Existence check on a mixed value (covered by flow/sketchy-null).

An existence check such as if (value) on a mixed value is false for null and undefined, and also for 0, "" and false, which the code usually did not mean to reject. Compare with null explicitly. Off by default: flow/sketchy-null covers it.

Bad

// @flow
export function present(value: mixed): boolean {
  if (value) {
    return true;
  }
  return false;
}

Good

// @flow
export function present(value: mixed): boolean {
  return value != null;
}

flow/sketchy-null-number

Default: off · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Existence check on a ?number (covered by flow/sketchy-null).

An existence check such as if (value) on a ?number is false both when the value is missing and when it is 0, and the code usually meant only one of them. Compare with null explicitly. Off by default: flow/sketchy-null covers it.

Bad

// @flow
export function describe(value: ?number): string {
  if (value) {
    return "set";
  }
  return "missing";
}

Good

// @flow
export function describe(value: ?number): string {
  if (value != null) {
    return "set";
  }
  return "missing";
}

flow/sketchy-null-string

Default: off · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Existence check on a ?string (covered by flow/sketchy-null).

An existence check such as if (value) on a ?string is false both when the value is missing and when it is "", and the code usually meant only one of them. Compare with null explicitly. Off by default: flow/sketchy-null covers it.

Bad

// @flow
export function describe(value: ?string): string {
  if (value) {
    return "set";
  }
  return "missing";
}

Good

// @flow
export function describe(value: ?string): string {
  if (value != null) {
    return "set";
  }
  return "missing";
}

flow/sketchy-number

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. A number in a boolean position renders or branches on 0.

A number on the left of && in JSX renders 0 when it is zero, instead of rendering nothing. Turn it into a boolean first.

Bad

// @flow
export component Unread(count: number) {
  return <p>{count && <span>{count} new</span>}</p>;
}

Good

// @flow
export component Unread(count: number) {
  return <p>{count > 0 && <span>{count} new</span>}</p>;
}

flow/syntax

Default: error. The file must parse with the official Flow parser.

The file must parse with the official Flow parser, the parser uf compiles with. When it does not, nothing else about the file can be checked, so this finding comes first.

Bad

// @flow
export const total = 1 +;

uf lint reports:

app/example.js:2:25 Unexpected token `;`

Good

// @flow
export type Row = { id: string };

flow/this-in-exported-function

Default: warn · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Avoid this inside an exported standalone function.

this in an exported standalone function depends on how each caller happens to call it, and it is undefined in a plain call from another module. Take the value as a parameter.

Bad

// @flow
export function fullName(): string {
  return `${this.first} ${this.last}`;
}

Good

// @flow
export function fullName(person: { readonly first: string, readonly last: string }): string {
  return `${person.first} ${person.last}`;
}

flow/unclear-type

Default: error. Avoid any, Object, and Function type annotations.

any, Object and Function switch Flow off for whatever they touch: a value typed any accepts every operation, and so does everything it flows into. Say what the value is instead: mixed when it could be anything, an object or function type when you know its shape.

Bad

// @flow
export type Props = { value: any };

uf lint reports:

app/example.js:2:30 avoid `any`; use `mixed`, opaque types, or generated router/action types

Good

// @flow
export type Props = { value: mixed };

flow/uninitialized-instance-property

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Do not read an instance property before the constructor initializes it.

Reading an instance property in the constructor before it has been assigned reads undefined, whatever its declared type says.

Bad

// @flow
export class Cache {
  size: number;
  entries: Map<string, string>;

  constructor() {
    this.size = this.entries.size;
    this.entries = new Map();
  }
}

Good

// @flow
export class Cache {
  entries: Map<string, string>;
  size: number;

  constructor() {
    this.entries = new Map();
    this.size = this.entries.size;
  }
}

flow/unnecessary-invariant

Default: warn · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. invariant on a condition already known to be truthy.

An invariant whose condition Flow already knows is true checks nothing, and suggests to a reader that the value could be missing when it cannot.

Bad

// @flow
import invariant from "invariant";

export function first(items: [string, string]): string {
  const head = items[0];
  invariant(head, "a pair has a first item");
  return head;
}

Good

// @flow
import invariant from "invariant";

export function first(items: $ReadOnlyArray<string>): string {
  const head = items[0];
  invariant(head != null, "the list is not empty");
  return head;
}

flow/unnecessary-optional-chain

Default: warn. ?. applied to a base that can never be nullish.

?. on a value that can never be null or undefined, such as this, suggests to a reader that it can be. Use a plain ..

Bad

// @flow
export class Timer {
  elapsed: number = 0;
  read(): number {
    return this?.elapsed;
  }
}

uf lint reports:

app/example.js:5:12 `this` is never nullish; drop the `?.`

Good

// @flow
export class Timer {
  elapsed: number = 0;
  read(): number {
    return this.elapsed;
  }
}

flow/unsafe-getters-setters

Default: warn. Avoid getters and setters; they hide side effects behind property access.

A getter or setter runs code when a property is read or written, where a reader expects a plain field. Flow also cannot track what the side effect changes. Use a method, so the call is visible.

Bad

// @flow
export class Temperature {
  celsius: number = 0;
  get fahrenheit(): number {
    return this.celsius * 1.8 + 32;
  }
}

uf lint reports:

app/example.js:4:3 avoid getters and setters; they hide side effects behind property access

Good

// @flow
export class Temperature {
  celsius: number = 0;
  fahrenheit(): number {
    return this.celsius * 1.8 + 32;
  }
}

flow/unsafe-object-assign

Default: error. Prefer object spread over Object.assign.

Object.assign mutates its first argument, and Flow types the merge less precisely than an object spread. Spread into a new object.

Bad

// @flow
export function withDefaults(options: { readonly size?: number }): { readonly size?: number } {
  return Object.assign({}, { size: 10 }, options);
}

uf lint reports:

app/example.js:3:10 prefer object spread over `Object.assign`, which mutates its target

Good

// @flow
export function withDefaults(options: { readonly size?: number }): { readonly size?: number } {
  return { size: 10, ...options };
}

flow/untyped-import

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Importing from an untyped module produces any.

Importing a value from a module Flow has no types for gives you any, which switches off checking for everything that value flows into. Add types for the module, or import from one that has them.

Bad

// @flow
import leftPad from "left-pad"; // no types, no library definition

export const padded: string = leftPad("7", 3, "0");

Good

// @flow
export const padded: string = "7".padStart(3, "0");

flow/untyped-type-import

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Importing a type from an untyped module produces an any alias.

Importing a type from a module Flow has no types for gives you an any alias, which checks nothing wherever you use it. Add types for the module, or declare the type yourself.

Bad

// @flow
import type { Options } from "legacy-widget"; // no types, no library definition

export const defaults: Options = { size: 10 };

Good

// @flow
export type Options = { readonly size: number };

export const defaults: Options = { size: 10 };

flow/unused-promise

Default: error · needs Flow type inference, which uf does not implement yet, so the rule does not run and the examples below are not checked. Do not ignore a Promise; await it or handle its rejection.

A Promise that nobody awaits or handles fails silently: its rejection becomes an unhandled rejection, and whatever comes next runs before it has settled. Await it, return it, or attach a handler.

Bad

// @flow
declare function save(value: string): Promise<void>;

export async function submit(value: string): Promise<void> {
  save(value);
}

Good

// @flow
declare function save(value: string): Promise<void>;

export async function submit(value: string): Promise<void> {
  await save(value);
}

react/button-has-type

Default: warn. A button defaults to submit, so say which kind it is.

A button with no type is a submit button. Inside a form, a button meant to open a menu or clear a field submits the form instead. Write type="button", type="submit" or type="reset" so the choice is on the page.

Bad

// @flow
export component Toolbar(onClear: () => void) {
  return <button onClick={onClear}>Clear</button>;
}

uf lint reports:

app/example.js:3:10 this `<button>` has no `type`, and HTML defaults one to `type="submit"`: inside a form it submits and navigates away, so whatever its `onClick` did is thrown away by the navigation. Write `type="button"` for a button that runs a handler, or `type="submit"` to say the submission is meant

Good

// @flow
export component Toolbar(onClear: () => void) {
  return (
    <button type="button" onClick={onClear}>
      Clear
    </button>
  );
}

react/checked-requires-onchange-or-readonly

Default: error. A checked input needs an onChange or a readOnly.

A checked input with no onChange is controlled by React and cannot be changed by anyone: every click is undone on the next render. Handle the change, mark it readOnly, or use defaultChecked for an uncontrolled box.

Bad

// @flow
export component Agree(accepted: boolean) {
  return <input type="checkbox" checked={accepted} />;
}

uf lint reports:

app/example.js:3:33 `checked` makes this input controlled, so React puts the prop's value back after every click and the reader cannot move it; add an `onChange` that stores the new value, or `readOnly` to say that not moving is what was meant. `defaultChecked` is the uncontrolled form, which a click does move

Good

// @flow
export component Agree(accepted: boolean, onToggle: (next: boolean) => void) {
  return (
    <input
      type="checkbox"
      checked={accepted}
      onChange={(event) => onToggle(event.currentTarget.checked)}
    />
  );
}

Good

// @flow
export component Remembered() {
  return <input type="checkbox" defaultChecked />;
}

react/component-syntax

Default: warn. Declare React components with Flow component syntax.

Flow's component syntax types props exactly, lets renders say what a component may render, and is what the React Compiler reads a component as. A function or arrow that returns JSX gets none of that.

Bad

// @flow
import * as React from "react";

export function Greeting({ name }: { name: string }): React.Node {
  return <p>Hello, {name}</p>;
}

uf lint reports:

app/example.js:4:1 prefer Flow `component` syntax for React components

Good

// @flow
export component Greeting(name: string) {
  return <p>Hello, {name}</p>;
}

Good

A component whose type says what it renders.

// @flow
component Item(label: string) {
  return <li>{label}</li>;
}

export component List(labels: $ReadOnlyArray<string>) renders* Item {
  return labels.map((label) => <Item key={label} label={label} />);
}

react/hook-syntax

Default: warn. Declare React hooks with Flow hook syntax.

Flow's hook syntax makes a hook a hook to the type checker: Flow then enforces the Rules of Hooks on its callers and knows its result follows React's rules. A plain function useX is just a function whose name looks like a hook.

Bad

// @flow
import { useState } from "react";

function useToggle(initial: boolean): [boolean, () => void] {
  const [on, setOn] = useState(initial);
  return [on, () => setOn(!on)];
}

export { useToggle };

uf lint reports:

app/example.js:4:1 prefer Flow `hook` syntax for React hooks

Good

// @flow
import { useState } from "react";

export hook useToggle(initial: boolean): [boolean, () => void] {
  const [on, setOn] = useState(initial);
  return [on, () => setOn(!on)];
}

react/jsx-key

Default: error. An element built in an array or by map needs a key.

React matches list items between renders by key. Without one it matches them by position, so state and focus stay where an item was rather than with the item when the list changes.

Bad

// @flow
type Todo = { id: string, title: string };

export component Todos(todos: $ReadOnlyArray<Todo>) {
  return <ul>{todos.map((todo) => <li>{todo.title}</li>)}</ul>;
}

uf lint reports:

app/example.js:5:35 `<li>` is returned from `map` with no `key`, so React matches the items by position and hands one item's state to another when the list is reordered or filtered; give it `key={…}` with the item's id

Good

// @flow
type Todo = { id: string, title: string };

export component Todos(todos: $ReadOnlyArray<Todo>) {
  return (
    <ul>
      {todos.map((todo) => (
        <li key={todo.id}>{todo.title}</li>
      ))}
    </ul>
  );
}

react/jsx-no-comment-textnodes

Default: error. // and /* between JSX tags are text on the page, not comments.

Between JSX tags, // and /* are text, not comments, so they end up on the page. A comment in JSX goes inside braces: {/* like this */}.

Bad

// @flow
export component Empty() {
  return <div>// nothing yet</div>;
}

uf lint reports:

app/example.js:3:15 `//` between JSX tags is text, not a comment, so it shows on the page; write `{/* … */}` to comment it out, or `{"// …"}` if the slashes are meant to be seen

Good

// @flow
export component Empty() {
  return <div>{/* nothing yet */}</div>;
}

react/jsx-no-duplicate-props

Default: error. Give each prop once; a repeated one silently replaces the first.

When a prop is written twice, the last one wins and the first is silently thrown away. It is almost always a copy-and-paste mistake.

Bad

// @flow
export component Avatar(src: string) {
  return <img src={src} alt="" alt="Profile picture" />;
}

uf lint reports:

app/example.js:3:32 `alt` is given twice on `<img>`, and only the last one reaches it; remove the one that was not meant

Good

// @flow
export component Avatar(src: string) {
  return <img src={src} alt="Profile picture" />;
}

react/no-array-index-key

Default: warn. Key a list item by what it is, not by where it stands.

An index key ties each item's state to its position. When the list is reordered, filtered or added to at the front, React hands one item's state, focus and input text to another. Key by something the item carries, such as its id.

Bad

// @flow
type Row = { id: string, name: string };

export component Rows(rows: $ReadOnlyArray<Row>) {
  return rows.map((row, index) => <input key={index} defaultValue={row.name} />);
}

uf lint reports:

app/example.js:5:42 `key` is built from the list index `index`, so React ties each item's state to its position and hands it to a different item when the list is reordered, filtered or added to at the front; key it by something the item carries, such as its id

Good

// @flow
type Row = { id: string, name: string };

export component Rows(rows: $ReadOnlyArray<Row>) {
  return rows.map((row) => <input key={row.id} defaultValue={row.name} />);
}

react/no-children-prop

Default: warn. Write children between the tags, not as a prop.

Children belong between the tags. Passed as a children prop they are easy to miss when reading, and anything nested between the tags silently replaces them.

Bad

// @flow
export component Notice(text: string) {
  return <p children={text} />;
}

uf lint reports:

app/example.js:3:13 pass `children` to `<p>` between its tags rather than as a prop, which is where a reader of JSX looks for them

Good

// @flow
export component Notice(text: string) {
  return <p>{text}</p>;
}

react/no-default-export-component

Default: warn. Modules that declare components must use named exports.

A named export keeps a component's name the same at every import site, so it can be searched for, renamed by tools and read in stack traces. uf's router reads a page module's default export or its named Page, so a named export works for routes too.

Bad

// @flow
component Settings() {
  return <h1>Settings</h1>;
}

export default Settings;

uf lint reports:

app/example.js:6:1 framework routes are wired by name; export components with a named export

Good

// @flow
export component Settings() {
  return <h1>Settings</h1>;
}

react/no-namespace

Default: error. React has no way to render a namespaced element name.

React cannot render a namespaced element name such as svg:rect. JSX parses it, but React DOM has no element to create for it. Write the element's own name.

Bad

// @flow
export component Dot() {
  return (
    <svg viewBox="0 0 10 10">
      <svg:circle cx="5" cy="5" r="5" />
    </svg>
  );
}

uf lint reports:

app/example.js:5:8 `<svg:circle>` is a namespaced element name, which React does not support: JSX reads a lowercase name as an HTML tag and a capitalised one as a value in scope, and `svg:circle` is neither, so there is nothing for React to render. Inside an `<svg>` the children are already in the SVG namespace — write `<circle>`

Good

// @flow
export component Dot() {
  return (
    <svg viewBox="0 0 10 10">
      <circle cx="5" cy="5" r="5" />
    </svg>
  );
}

react/no-redundant-memo

Default: warn. Drop a useMemo/useCallback the React Compiler already did.

The React Compiler memoizes every component and hook it compiles. A hand-written useMemo or useCallback in one of them is a second copy of work the compiler already did, with a dependency array that someone now has to keep correct. The rule reports only memoization the compiler removed.

Bad

// @flow
import { useMemo } from "react";

export component Total(prices: $ReadOnlyArray<number>) {
  const total = useMemo(() => prices.reduce((sum, price) => sum + price, 0), [prices]);
  return <output>{total}</output>;
}

uf lint reports:

app/example.js:5:17 the React Compiler memoizes this already; `useMemo` here is a second dependency array to keep correct

Good

// @flow
export component Total(prices: $ReadOnlyArray<number>) {
  const total = prices.reduce((sum, price) => sum + price, 0);
  return <output>{total}</output>;
}

react/no-this-in-sfc

Default: error. this names nothing inside a component or hook.

A component or hook is a function called by React, not a method, so this inside one is undefined. It usually means code was moved over from a class component and still reads this.props.

Bad

// @flow
export component Title(text: string) {
  return <h1>{this.props.text}</h1>;
}

uf lint reports:

app/example.js:3:15 `this` names nothing inside a `component`: Flow calls one as a plain function, so `this` is `undefined` here and reading anything off it throws; take the value from a parameter, or from the scope around the declaration

Good

// @flow
export component Title(text: string) {
  return <h1>{text}</h1>;
}

react/no-unescaped-entities

Default: warn. A > or } left in JSX text is usually a mistyped tag.

A > or } in JSX text is legal, but it is usually a tag or an expression typed one character wrong. Write the character as an entity, or as a string in braces, when you mean it.

Bad

// @flow
export component Breadcrumb() {
  return <p>Home > Settings</p>;
}

uf lint reports:

app/example.js:3:18 `>` in JSX text renders as itself, and is usually what a mistyped tag or a dropped brace left behind; write `>` if it is meant to be read

Good

// @flow
export component Breadcrumb() {
  return <p>Home &gt; Settings</p>;
}

react/no-unknown-property

Default: error. Write the prop React spells, not the HTML attribute name.

React spells some DOM attributes differently from HTML: className, htmlFor, tabIndex. React warns about the HTML spelling at run time and may drop it; this reports it while you write it.

Bad

// @flow
export component Field() {
  return (
    <label class="field" for="email">
      Email
    </label>
  );
}

uf lint reports:

app/example.js:4:12 `class` is the HTML spelling of this attribute and React spells the prop `className`, so the name written on this `<label>` is not the one React binds and whatever it was meant to do does not happen — React reports it as an unknown DOM property in development. Write `className`
app/example.js:4:26 `for` is the HTML spelling of this attribute and React spells the prop `htmlFor`, so the name written on this `<label>` is not the one React binds and whatever it was meant to do does not happen — React reports it as an unknown DOM property in development. Write `htmlFor`

Good

// @flow
export component Field() {
  return (
    <label className="field" htmlFor="email">
      Email
    </label>
  );
}

react/no-unused-prop-types

Default: off. A prop a component declares should be read by its body.

A prop that a component declares and never reads is part of its type that does nothing. Callers keep passing it for no effect. Remove it, or use it.

Bad

// @flow
export component Badge(label: string, tone: "info" | "warning") {
  return <span>{label}</span>;
}

uf lint reports:

app/example.js:2:39 `<Badge>` declares the prop `tone` and never reads it, so every caller is asked for a value that goes nowhere; read it, or drop it from the parameter list

Good

// @flow
export component Badge(label: string, tone: "info" | "warning") {
  return <span data-tone={tone}>{label}</span>;
}

react/style-prop-object

Default: error. style takes an object; React throws on anything else.

React's style takes an object of properties, not a CSS string. A string throws at render time.

Bad

// @flow
export component Spacer() {
  return <div style="height: 1rem" />;
}

uf lint reports:

app/example.js:3:15 `style` on this `<div>` is a string, and React's `style` prop takes an object mapping property names to values — it throws on anything else rather than rendering it, so this is a crash rather than a matter of taste. Write `style={{ color: "red" }}`, with the property names camelCased

Good

// @flow
export component Spacer() {
  return <div style={{ height: "1rem" }} />;
}

react/void-dom-elements-no-children

Default: error. Void elements such as img and br take no children.

img, br, input and the other void elements cannot have children in HTML. React throws when it is given some.

Bad

// @flow
export component Photo(src: string) {
  return <img src={src}>A cat asleep</img>;
}

uf lint reports:

app/example.js:3:10 `<img>` is a void element and cannot hold children: React throws when it renders one that does; put the content next to it instead

Good

// @flow
export component Photo(src: string) {
  return <img src={src} alt="A cat asleep" />;
}

react-compiler/capitalized-calls

Default: off. The React Compiler's CapitalizedCalls diagnostics: a capitalized function called instead of rendered with JSX.

A function whose name starts with a capital is read as a component. Called like a function, it runs inside the caller's render with the caller's hooks, and the compiler cannot tell a component call from a plain function call. Render components with JSX; give helpers lower-case names.

Bad

// @flow
import { FormatPrice } from "./format.js";

export component Price(amount: number) {
  const text = FormatPrice(amount);
  return <span>{text}</span>;
}

uf lint reports:

app/example.js:5:16 Capitalized functions are reserved for components, which must be invoked with JSX. If this is a component, render it with JSX. Otherwise, ensure that it has no hook calls and rename it to begin with a lowercase letter. Alternatively, if you know for a fact that this function is not a component, you can allowlist it via the compiler config. FormatPrice may be a component.

Good

// @flow
import { formatPrice } from "./format.js";

export component Price(amount: number) {
  const text = formatPrice(amount);
  return <span>{text}</span>;
}

react-compiler/error-boundaries

Default: error. The React Compiler's ErrorBoundaries diagnostics: JSX built inside try/catch instead of under an error boundary.

try/catch around JSX does not catch errors thrown while rendering it: the element is only a description, and React renders it later, outside the try. Put an error boundary around the subtree instead.

Bad

// @flow
import { Chart } from "./chart.js";

export component Panel(data: $ReadOnlyArray<number>) {
  let content;
  try {
    content = <Chart data={data} />;
  } catch {
    content = <p>Could not draw the chart.</p>;
  }
  return content;
}

uf lint reports:

app/example.js:7:15 Avoid constructing JSX within try/catch. React does not immediately render components when JSX is rendered, so any errors from this component will not be caught by the try/catch. To catch errors in rendering a given component, wrap that component in an error boundary. (https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary).

Good

// @flow
import { ErrorBoundary } from "@uniflowed/react";
import { Chart } from "./chart.js";

export component Panel(data: $ReadOnlyArray<number>) {
  return (
    <ErrorBoundary fallback={<p>Could not draw the chart.</p>}>
      <Chart data={data} />
    </ErrorBoundary>
  );
}

react-compiler/exhaustive-effect-dependencies

Default: off. The React Compiler's EffectExhaustiveDependencies diagnostics: an effect's dependency array missing or adding a value.

An effect's dependency array says when it runs again. A value read inside the effect and missing from the array leaves the effect using a stale value; a value listed but never read re-runs it for nothing. Off by default, as in eslint-plugin-react-hooks.

Bad

// @flow
import { useEffect } from "react";

export component Title(count: number) {
  useEffect(() => {
    document.title = `${count} unread`;
  }, []);
  return null;
}

uf lint reports:

app/example.js:6:25 Found missing effect dependencies. Missing dependencies can cause an effect to fire less often than it should.

Good

// @flow
import { useEffect } from "react";

export component Title(count: number) {
  useEffect(() => {
    document.title = `${count} unread`;
  }, [count]);
  return null;
}

react-compiler/fbt

uf does not report this yet. It runs, but react_compiler 0.1.0 never files a diagnostic under FBT. A malformed fbt tag is reported as Invariant or Todo instead, so this rule has nothing to report yet. The Bad example below is what the category is about.

Default: off. The React Compiler's FBT diagnostics, about Meta's fbt internationalization library.

Meta's fbt internationalization library has JSX with rules of its own, and the compiler checks the parts it has to understand to compile it. Off by default: most projects do not use fbt.

Bad

An fbt tag must be the module-level import, not a local value that happens to be called fbt.

// @flow
export component Greeting(fbt: (text: string) => string) {
  return <fbt desc="Greeting">Hello</fbt>;
}

Good

// @flow
import fbt from "fbt";

export component Greeting(name: string) {
  return (
    <fbt desc="Greeting">
      Hello, <fbt:param name="name">{name}</fbt:param>
    </fbt>
  );
}

react-compiler/globals

Default: error. The React Compiler's Globals diagnostics: a variable from outside a component or hook changed during render.

Rendering must not change anything outside the component. A module variable reassigned during render changes on every render, including renders React throws away, and differs between the server and the browser.

Bad

// @flow
let renders = 0;

export component Counter() {
  renders = renders + 1;
  return <p>Rendered {renders} times</p>;
}

uf lint reports:

app/example.js:5:3 Cannot reassign variables declared outside of the component/hook. Variable `renders` is declared outside of the component/hook. Reassigning this value during render is a form of side effect, which can cause unpredictable behavior depending on when the component happens to re-render. If this variable is used in rendering, use useState instead. Otherwise, consider updating it in an effect. (https://react.dev/reference/rules/components-and-hooks-must-be-pure#side-effects-must-run-outside-of-render).

Good

// @flow
import { useRef, useEffect } from "react";

export component Counter() {
  const renders = useRef(0);
  useEffect(() => {
    renders.current += 1;
  });
  return <p>Counting renders in an effect</p>;
}

react-compiler/hooks

Default: error. The React Compiler's Hooks diagnostics: the Rules of Hooks.

The Rules of Hooks: call hooks at the top level of a component or hook, in the same order on every render. React matches each call to its state by position, so a hook behind a condition hands one hook's state to another.

Bad

// @flow
import { useState } from "react";

export component Search(enabled: boolean) {
  if (!enabled) {
    return null;
  }
  const [query, setQuery] = useState("");
  return <input value={query} onChange={(event) => setQuery(event.currentTarget.value)} />;
}

uf lint reports:

app/example.js:8:29 Hooks must always be called in a consistent order, and may not be called conditionally. See the Rules of Hooks (https://react.dev/warnings/invalid-hook-call-warning)

Good

// @flow
import { useState } from "react";

export component Search(enabled: boolean) {
  const [query, setQuery] = useState("");
  if (!enabled) {
    return null;
  }
  return <input value={query} onChange={(event) => setQuery(event.currentTarget.value)} />;
}

react-compiler/immutability

Default: error. The React Compiler's Immutability diagnostics: props, state or another value React treats as immutable, mutated.

Props, state, context and values returned from hooks belong to React and must not be mutated. A mutation changes a value that React and the compiler assume did not change, so the screen and the data disagree. Copy the value and change the copy.

Bad

// @flow
export component Name(user: { name: string }) {
  user.name = user.name.trim();
  return <p>{user.name}</p>;
}

uf lint reports:

app/example.js:3:3 This value cannot be modified. Modifying component props or hook arguments is not allowed. Consider using a local variable instead.

Bad

A context value is shared by every component that reads it.

// @flow
import { useContext } from "react";
import { Settings } from "./settings.js";

export component Theme() {
  const settings = useContext(Settings);
  settings.theme = "dark";
  return <p>{settings.theme}</p>;
}

uf lint reports:

app/example.js:7:3 This value cannot be modified. Modifying a value returned from 'useContext()' is not allowed.

Good

// @flow
export component Name(user: { name: string }) {
  const name = user.name.trim();
  return <p>{name}</p>;
}

react-compiler/incompatible-library

Default: warn. The React Compiler's IncompatibleLibrary diagnostics: an API known to break memoization.

Some libraries return functions or objects whose results change without their identity changing, which memoization cannot see. The compiler knows which APIs these are and skips memoizing the code that uses them. This reports that it did, so a missing update is not a mystery.

Bad

// @flow
import { useVirtualizer } from "@tanstack/react-virtual";

export component Rows(count: number, parent: { current: HTMLElement | null }) {
  const virtualizer = useVirtualizer({
    count,
    getScrollElement: () => parent.current,
    estimateSize: () => 32,
  });
  return <div>{virtualizer.getVirtualItems().length}</div>;
}

uf lint reports:

app/example.js:5:23 Use of incompatible library. This API returns functions which cannot be memoized without leading to stale UI. To prevent this, by default React Compiler will skip memoizing this component/hook. However, you may see issues if values from this API are passed to other components/hooks that are memoized.

Good

// @flow
export component Rows(labels: $ReadOnlyArray<string>) {
  return labels.map((label) => <div key={label}>{label}</div>);
}

react-compiler/invariant

Default: off. The React Compiler's Invariant diagnostics: an internal assumption of the compiler that did not hold.

An internal assumption of the React Compiler that did not hold: a bug in the compiler, not a rule your code broke. The function is left uncompiled and runs as written. Off by default; turn it on when you want to know which functions the compiler gave up on, or to report a compiler bug.

Bad

A named function expression that refers to itself trips an assertion in this compiler version.

// @flow
export component Countdown(from: number) {
  const tick = function step(n: number): $ReadOnlyArray<number> {
    return n <= 0 ? [] : [n, ...step(n - 1)];
  };
  return <p>{tick(from).join(", ")}</p>;
}

uf lint reports:

app/example.js:4:33 [InferMutationAliasingEffects] Expected value kind to be initialized. <unknown> step$8:TFunction.

Good

// @flow
function step(n: number): $ReadOnlyArray<number> {
  return n <= 0 ? [] : [n, ...step(n - 1)];
}

export component Countdown(from: number) {
  return <p>{step(from).join(", ")}</p>;
}

react-compiler/memo-dependencies

Default: warn. The React Compiler's MemoDependencies diagnostics: a useMemo or useCallback dependency array missing or adding a value.

A useMemo or useCallback recomputes when one of its dependencies changes. A value it reads but does not list leaves it returning a stale result; a value listed but not read recomputes it for nothing.

Bad

// @flow
import { useMemo } from "react";

export component Total(price: number, quantity: number) {
  const total = useMemo(() => price * quantity, [price]);
  return <output>{total}</output>;
}

uf lint reports:

app/example.js:5:39 Found missing memoization dependencies. Missing dependencies can cause a value to update less often than it should, resulting in stale UI.

Good

// @flow
import { useMemo } from "react";

export component Total(price: number, quantity: number) {
  const total = useMemo(() => price * quantity, [price, quantity]);
  return <output>{total}</output>;
}

react-compiler/no-deriving-state-in-effects

Default: off. The React Compiler's EffectDerivationsOfState diagnostics: a value derived from props or state, computed in an effect.

State computed from props or other state in an effect renders twice: once with the stale value, then again with the new one. Compute the value during render instead. Off by default, as in eslint-plugin-react-hooks.

Bad

// @flow
import { useEffect, useState } from "react";

export component Name(first: string, last: string) {
  const [full, setFull] = useState("");
  useEffect(() => {
    setFull(`${first} ${last}`);
  }, [first, last]);
  return <p>{full}</p>;
}

uf lint reports:

app/example.js:7:5 Values derived from props and state should be calculated during render, not in an effect. (https://react.dev/learn/you-might-not-need-an-effect#updating-state-based-on-props-or-state)

Good

// @flow
export component Name(first: string, last: string) {
  const full = `${first} ${last}`;
  return <p>{full}</p>;
}

react-compiler/preserve-manual-memoization

uf does not report this yet. It runs, but under the options uf and eslint-plugin-react-hooks run the compiler with, the shapes that break a manual memo are reported first as react-compiler/memo-dependencies or react-compiler/immutability, and compilation of that function stops before this check runs. The Bad example below is what the category is about.

Default: error. The React Compiler's PreserveManualMemo diagnostics: a useMemo or useCallback the compiler cannot preserve.

The compiler keeps every useMemo and useCallback it finds, so code that relies on a memoized value keeping its identity still works. When a dependency is changed after the memo reads it, the compiler cannot promise the same identity and skips the component instead of memoizing it differently.

Bad

// @flow
import { useMemo } from "react";
import { track } from "./track.js";

export component Count(a: number) {
  const list = [a];
  const size = useMemo(() => list.length, [list]);
  track(list);
  return <p>{size}</p>;
}

Good

// @flow
import { useMemo } from "react";
import { track } from "./track.js";

export component Count(a: number) {
  const list = [a];
  track(list);
  const size = useMemo(() => list.length, [list]);
  return <p>{size}</p>;
}

react-compiler/purity

Default: error. The React Compiler's Purity diagnostics: a known-impure function called during render.

Rendering must be pure: the same props and state give the same output. Date.now(), Math.random() and similar calls give a different answer on every render, and a different one again on the server.

Bad

// @flow
export component Stamp() {
  const now = Date.now();
  return <time>{now}</time>;
}

uf lint reports:

app/example.js:3:15 Cannot call impure function during render. `Date.now` is an impure function. Calling an impure function can produce unstable results that update unpredictably when the component happens to re-render. (https://react.dev/reference/rules/components-and-hooks-must-be-pure#components-and-hooks-must-be-idempotent).

Good

// @flow
export component Stamp(now: number) {
  return <time>{now}</time>;
}

react-compiler/refs

Default: error. The React Compiler's Refs diagnostics: a ref read or written during render.

A ref is a value React does not track. Reading or writing ref.current during render shows whatever it held last time and does not update the screen when it changes. Use refs in effects and event handlers, and state for what is rendered.

Bad

// @flow
import { useRef } from "react";

export component Clicks() {
  const count = useRef(0);
  return <button type="button" onClick={() => { count.current += 1; }}>{count.current}</button>;
}

uf lint reports:

app/example.js:6:73 Cannot access refs during render. React refs are values that are not needed for rendering. Refs should only be accessed outside of render, such as in event handlers or effects. Accessing a ref value (the `current` property) during render can cause your component not to update as expected (https://react.dev/reference/react/useRef).

Good

// @flow
import { useState } from "react";

export component Clicks() {
  const [count, setCount] = useState(0);
  return (
    <button type="button" onClick={() => setCount(count + 1)}>
      {count}
    </button>
  );
}

react-compiler/set-state-in-effect

Default: error. The React Compiler's EffectSetState diagnostics: setState called synchronously in an effect.

Setting state synchronously in an effect renders the component a second time straight after the first. Effects are for synchronizing with things outside React; derive the value during render, or set it from the event that caused it.

Bad

// @flow
import { useEffect, useState } from "react";

export component Filtered(items: $ReadOnlyArray<string>, query: string) {
  const [visible, setVisible] = useState<$ReadOnlyArray<string>>([]);
  useEffect(() => {
    setVisible(items.filter((item) => item.includes(query)));
  }, [items, query]);
  return <p>{visible.length} matches</p>;
}

uf lint reports:

app/example.js:7:5 Calling setState synchronously within an effect can trigger cascading renders. Effects are intended to synchronize state between React and external systems such as manually updating the DOM, state management libraries, or other platform APIs. In general, the body of an effect should do one or both of the following: * Update external systems with the latest state from React. * Subscribe for updates from some external system, calling setState in a callback function when external state changes. Calling setState synchronously within an effect body causes cascading renders that can hurt performance, and is not recommended. (https://react.dev/learn/you-might-not-need-an-effect).

Good

// @flow
export component Filtered(items: $ReadOnlyArray<string>, query: string) {
  const visible = items.filter((item) => item.includes(query));
  return <p>{visible.length} matches</p>;
}

react-compiler/set-state-in-render

Default: error. The React Compiler's RenderSetState diagnostics: setState called during render.

Setting state unconditionally during render starts another render, which sets it again: an infinite loop that React stops with an error.

Bad

// @flow
import { useState } from "react";

export component Greeting(name: string) {
  const [text, setText] = useState("");
  setText(`Hello, ${name}`);
  return <p>{text}</p>;
}

uf lint reports:

app/example.js:6:3 Cannot call setState during render. Calling setState during render may trigger an infinite loop. * To reset state when other state/props change, store the previous value in state and update conditionally: https://react.dev/reference/react/useState#storing-information-from-previous-renders * To derive data from other state/props, compute the derived data during render without using state.

Good

// @flow
export component Greeting(name: string) {
  const text = `Hello, ${name}`;
  return <p>{text}</p>;
}

react-compiler/static-components

Default: error. The React Compiler's StaticComponents diagnostics: a component created during render.

A component created during render is a new component on every render, so React unmounts the old one and mounts the new one, throwing away its state and its DOM. Declare components at the top level of the module, and choose between existing ones instead of building one.

Bad

// @flow
export component Card(title: string) {
  const Heading = () => <h2>{title}</h2>;
  return (
    <section>
      <Heading />
    </section>
  );
}

uf lint reports:

app/example.js:6:8 Cannot create components during render. Components created during render will reset their state each time they are created. Declare components outside of render.

Bad

// @flow
import { makeField } from "./fields.js";

export component Field(kind: string) {
  const Input = makeField(kind);
  return <Input />;
}

uf lint reports:

app/example.js:6:11 Cannot create components during render. Components created during render will reset their state each time they are created. Declare components outside of render.

Good

// @flow
component Heading(title: string) {
  return <h2>{title}</h2>;
}

export component Card(title: string) {
  return (
    <section>
      <Heading title={title} />
    </section>
  );
}

react-compiler/syntax

Default: off. The React Compiler's Syntax diagnostics: code the compiler rejects as invalid syntax.

Code the React Compiler rejects as invalid, even though the parser accepted it. Off by default: flow/syntax and uf check report most of what a module gets wrong.

Bad

// @flow
export component Counter() {
  const count = 0;
  count = 1;
  return <p>{count}</p>;
}

uf lint reports:

app/example.js:4:3 Cannot reassign a `const` variable. `count` is declared as const.

Good

// @flow
export component Counter() {
  let count = 0;
  count = 1;
  return <p>{count}</p>;
}

react-compiler/todo

Default: off. The React Compiler's Todo diagnostics: code the compiler does not compile yet.

Code the React Compiler cannot compile yet. The function is left as it is, unmemoized, and the rest of the module is still compiled. Off by default: nothing is wrong with the code, and the finding says what the compiler skipped.

Bad

// @flow
export component Temperature(celsius: number) {
  const reading = {
    get fahrenheit(): number {
      return (celsius * 9) / 5 + 32;
    },
  };
  return <p>{reading.fahrenheit}°F</p>;
}

uf lint reports:

app/example.js:4:5 (BuildHIR::lowerExpression) Handle get functions in ObjectExpression

Good

// @flow
export component Temperature(celsius: number) {
  const fahrenheit = (celsius * 9) / 5 + 32;
  return <p>{fahrenheit}°F</p>;
}

react-compiler/unsupported-syntax

Default: warn. The React Compiler's UnsupportedSyntax diagnostics: syntax the compiler does not support.

Syntax the React Compiler will not compile, such as eval or with, whose effects on the surrounding variables it cannot see. The function is left uncompiled.

Bad

// @flow
export component Formula(source: string) {
  const value = eval(source);
  return <output>{String(value)}</output>;
}

uf lint reports:

app/example.js:3:17 The 'eval' function is not supported. Eval is an anti-pattern in JavaScript, and the code executed cannot be evaluated by React Compiler.

Good

// @flow
import { evaluate } from "./formula.js";

export component Formula(source: string) {
  const value = evaluate(source);
  return <output>{String(value)}</output>;
}

react-compiler/use-memo

Default: error. The React Compiler's UseMemo diagnostics: a useMemo callback that is async, a generator, or takes parameters.

useMemo calls its callback with no arguments and keeps what it returns. An async callback memoizes a promise, a generator memoizes an iterator, and a parameter is always undefined.

Bad

// @flow
import { useMemo } from "react";

export component Profile(id: string) {
  const user = useMemo(async () => {
    const response = await fetch(`/users/${id}`);
    return response.json();
  }, [id]);
  return <pre>{String(user)}</pre>;
}

uf lint reports:

app/example.js:5:24 useMemo() callbacks may not be async or generator functions. useMemo() callbacks are called once and must synchronously return a value.

Good

// @flow
import { use, useMemo } from "react";

export component Profile(id: string) {
  const user = useMemo(() => fetch(`/users/${id}`).then((response) => response.json()), [id]);
  return <pre>{String(use(user))}</pre>;
}