Glossary

A short glossary of Flow terminology. Each entry is a one-sentence definition followed by a link to the full reference page. Where helpful, an entry also notes how the concept relates to a similar one in TypeScript.

Type system

• Refinement — Narrowing a value's type inside a branch based on a runtime test such as typeof, instanceof, equality, or a type guard. See Type Refinements.
• Refinement invalidation — When a previously established refinement is dropped because intervening code (such as a function call or a write to the refined location) might have changed the underlying value, requiring the check to be re-done; TypeScript's narrowing has its own invalidation model that does not agree with Flow's in detail (more). See Refinement Invalidations.
• Maybe type (?T) — Flow shorthand for the union T | null | void, used to express values that may be absent; TypeScript has no direct equivalent and typically writes T | null | undefined (more). See Maybe Types.
• Exact object type — An object type that allows exactly the listed properties and no others, which is the default in Flow (the opposite of TypeScript, where object types are open) (more). See Exact and inexact object types.
• Inexact object type — An object type written with a trailing ... (e.g. {foo: number, ...}) that allows additional unknown properties beyond those listed; TypeScript object types are open by default and have no syntactic inexact marker (more). See Exact and inexact object types.
• Object type spread — Including the properties of another object type via ... (e.g. {...A, b: T}), producing a new object type that combines A's properties with the additional members, mirroring runtime object spread; TypeScript has no type-level spread and uses intersection (A & {b: T}) instead (more). See Object type spread.
• Indexer property — An object type member of the form [key: K]: V that allows reads and writes for any key whose type matches K and any value whose type matches V, used to type objects that are used as maps. See Objects as maps.
• Disjoint union — A union of separate object types (e.g. {type: 'A', value: number} | {type: 'B', error: string}) that each set a different literal type for a shared discriminant property, letting Flow refine the union to a specific arm by checking that property. See Disjoint Object Unions.
• Opaque type — A type alias whose underlying type is hidden outside the file in which it is defined, enforcing abstraction across module boundaries; this concept does not exist in TypeScript, whose closest userland pattern (branded types) is weaker because a single as cast can forge a branded value (more). See Opaque Type Aliases.
• Empty type — Flow's bottom type, the subtype of every other type, used for functions that never return and for exhaustiveness assertions; TypeScript's analogue is called never (more). See Empty.
• Width subtyping — The rule that an object type with more properties is a subtype of one with fewer properties (only valid against inexact object types in Flow); much narrower than in TypeScript, where object types are open by default (more). See Object Subtyping.
• Depth subtyping — The rule that an object type with a subtype property at some key is a subtype of one with a supertype property at that key, which is only sound for read-only properties; TypeScript treats mutable properties covariantly anyway, while Flow makes them invariant (more). See Object Subtyping.
• Nominal typing — Type compatibility determined by declaration identity rather than shape, which Flow uses for classes, opaque types (outside their defining file), and Flow Enums; TypeScript is primarily structural with narrow nominal carve-outs (#private fields, private/protected modifiers, unique symbol) (more). See Nominal & Structural Typing.
• Structural typing — Type compatibility determined by the shape of a type, which Flow uses for objects and interfaces. See Nominal & Structural Typing.
• Local Type Inference — Flow's inference algorithm, which propagates types from immediate context but requires annotations at function parameters and other key boundaries. See Annotation Requirement.
• One-sided type guard (implies) — A predicate function whose return type is implies param is T, which refines the parameter to T only when the function returns true and leaves it unchanged otherwise; this has no TypeScript equivalent (more). See Type Guards.
• Method unbinding — Flow disallows extracting a class method as a bare function value (e.g. obj.method without calling it, destructuring it, or .bind()-ing it), since doing so would lose the this type that the method depends on; TypeScript treats methods as plain function values and lets the same extraction through silently (more). See Method unbinding.
• Input position / Output position — The terminology Flow's variance error messages use to refer to where a value is written into a type (input — function parameters, writable properties) versus read out of a type (output — return types, readable properties). Flow and TypeScript share the same variance syntax — in T / out T on type parameters, readonly / writeonly on properties — but Flow's variance rules are stricter at several places (mutable properties, mutable arrays, method parameters, generic type arguments) (more). See Input and Output Positions.

Modules and declarations

• import typeof — A Flow-specific import form that brings in the type of a value export from another module so it can be used as a type annotation; TypeScript's nearest analogue is typeof import('./m')['Foo'] with a different binding shape (more). See Module Types.
• Declaration file (.js.flow) — A .flow file placed next to a .js implementation that completely shadows the implementation's types when Flow is checking code; TypeScript's .d.ts covers both this case and the third-party-package case that Flow handles via libdefs (more). See Declaration Files.
• Libdef (library definition) — A special file under flow-typed/ that declares the type signature of a third-party module Flow cannot type-check directly; TypeScript's equivalent is @types/* packages and package-level .d.ts files (more). See Library Definitions.
• Signature extraction / typed interface — Flow builds a per-module "typed interface" from the module's exports alone (without analyzing the implementation), which is what enables parallel typechecking and is what the [signature-verification-failure] error refers to when it cannot do so; TypeScript has no equivalent and infers exports across module bodies (more). See Module Exports.

React

• Component syntax (component) — A first-class Flow keyword for declaring React components with named props, optional ref, and render-type support, replacing hand-written function-component types; TypeScript has no built-in component syntax and models the equivalent shape with function types (more). See Component Syntax.
• Component type (component(...)) — The type-level form of Component Syntax, used to describe the type of a React component (especially in libdefs and HOCs) without defining one. See Component Types.
• Render type (renders) — A type that constrains what a component is allowed to render, enabling library authors to enforce composition rules like "a Menu only renders MenuItems"; TypeScript has no built-in render-constraint type (more). See Render Types.
• Hook syntax (hook) — A first-class Flow keyword for declaring React hooks, which lets Flow enforce the Rules of React on hook call sites; TypeScript has no equivalent and relies on ESLint (eslint-plugin-react-hooks) to enforce hook rules without type information (more). See Hook Syntax.

Language features

• Flow Enum — A fixed set of constants that exists at runtime and as a type, with built-in exhaustiveness checking and no implicit coercion to its underlying primitive; semantically distinct from TypeScript enum along several axes (exhaustiveness, coercion, default values, reverse mapping, member iteration, symbol enums) (more). See Flow Enums.
• Match expression / match statement — A match (...) { pattern => ... } construct that pattern-matches a value with structural patterns, guards, and exhaustiveness checking; TypeScript has no match, and the closest statement-form analogue is a discriminated-union switch with an assertNever fallthrough — there is no expression-form analogue at all (more). See Match Expressions and Statements.
• Exhaustiveness checking — Verification that every possible value of an input has been handled, supported built-in by match and by switch over Flow Enums, or on demand for arbitrary switch statements by casting the default branch to empty.

Workflow

• @flow pragma — A // @flow comment at the top of a file that, by default, opts that file into Flow type checking. See Getting Started.
• Flow Strict (@flow strict / @flow strict-local) — A file-level pragma that turns on a configurable set of stricter lint rules (banning any, etc.) on a per-file basis; the more common @flow strict-local variant is the same but does not require dependencies to also be strict. See Flow Strict.
• Suppression ($FlowFixMe[code]) — A comment placed immediately above a Flow error that silences that specific error code without fixing the underlying issue, used when Flow is too conservative or a fix is deferred. See Error Suppressions.
• Flowlint — Flow's built-in lint system, which reports stylistic or risky patterns (e.g. sketchy-null, untyped-import) on top of regular type errors. See Linting Overview.