react-table-sticky

react-table-sticky is a small plugin hook for React Table v7 that solves a common but fiddly UI problem: keeping table headers, footers, and specific columns fixed in place while the rest of a wide or tall table scrolls. Rather than shipping its own table component, it plugs directly into React Table’s hooks system as a useSticky plugin, injecting the inline styles and data-sticky-* attributes needed to make CSS position: sticky work correctly across header groups, grouped columns, and cell boundaries.

The library is intentionally minimal — it has zero runtime dependencies and ships only the logic for computing sticky offsets (left margin for left-pinned columns, right margin for right-pinned columns) and detecting group/column edge cases that would otherwise break the sticky CSS. Styling is left entirely to the consumer, which keeps the library flexible for teams already using styled-components, CSS Modules, or plain CSS with React Table’s headless useBlockLayout approach.

What You Get

• A useSticky hook that plugs into React Table v7’s getHeaderProps and getCellProps hook pipeline
• Automatic computation of left/right pixel offsets for pinned columns via getStickyValue and getMarginRight
• Data attributes (data-sticky-td, data-sticky-last-left-td, data-sticky-first-right-td) for targeted CSS styling of sticky boundaries
• Built-in validation that throws a descriptive error when sticky columns are misconfigured relative to column groups
• Zero runtime dependencies beyond a react-table v7 peer dependency

Common Use Cases

• Wide data-grid tables where the first column (e.g. row labels or IDs) should stay visible while scrolling horizontally
• Dashboards with tall tables that need a persistently visible header row while scrolling vertically
• Financial or spreadsheet-style UIs that pin both an ID column on the left and an actions/total column on the right
• Tables with grouped/nested headers that still need specific column groups to stick during horizontal scroll

Under The Hood

Architecture The entire library lives in a single src/index.tsx module that exports one plugin function, useSticky, following React Table v7’s plugin-hook convention of pushing callbacks onto hooks.getHeaderProps and hooks.getCellProps. Each callback receives the current header or cell along with the table instance, computes a getStickyProps(header, instance) result, and returns merged props back into React Table’s rendering pipeline — there is no independent rendering path or component tree of its own, so behavior is entirely driven by React Table’s existing hook composition model. A small set of pure helper functions (getStickyValue, columnIsLastLeftSticky, columnIsFirstRightSticky, getMarginRight) walk the column/parent-group tree and the flattened header list to compute pixel offsets and edge-of-sticky-region flags, and checkErrors runs on every render pass to fail fast with a descriptive message if sticky columns are declared outside a column group when the table also has grouped headers — a documented React Table v7 constraint. What breaks if the core abstraction (React Table’s hook composition) changes: this plugin has no fallback path and would need to be rewritten against any breaking change to React Table’s useTable hook contract.

Tech Stack Written in TypeScript (~86% of the codebase) and compiled with tsc against a tsconfig.build.json, targeting a CommonJS build/ output with generated .d.ts typings as declared in package.json’s main/typings fields. The only peer expectation is react-table v7 (the project’s own devDependencies pin react-table@7.0.0, react@^16.10.2, and styled-components@^4.4.1 for the bundled demo, built via Webpack 4 and webpack-dev-server). Linting runs through ESLint with the Airbnb TypeScript config and eslint-plugin-react/react-hooks; there is no CI configuration checked into the repo, so lint and test scripts (npm run test) are the extent of the verification step available to contributors.

Code Quality A single Jest test file (src/__tests__/index.spec.ts) exercises the pure helper functions directly — getStickyValue, columnIsLastLeftSticky, columnIsFirstRightSticky — with hand-constructed column fixtures rather than a rendered table, giving reasonable coverage of the offset/edge-detection logic but none of the actual hook-integration behavior (getStickyProps, the useSticky hook itself) or the error-throwing validation path. Types are used loosely in places (any appears for Column, header, and columns parameters, with @ts-ignore used twice to bypass strict property checks), which is a pragmatic but visible tradeoff given the library wraps React Table’s own loosely-typed v7 plugin API. Naming is clear and functions are short and single-purpose; there is no CI pipeline configured, so quality gates run only locally via npm test.

What Makes It Unique Unlike table libraries that bundle a complete sticky-table component with prescribed markup and styling, react-table-sticky is purely a props-and-attributes computation layer: it hands back inline styles and data-sticky-* attributes and leaves all actual CSS (background colors, shadows, borders) to the consumer, which is why its own README recommends copying a documented CSS snippet rather than importing bundled styles. Its most specific technical contribution is the column-group validation logic (checkErrors) that proactively catches a known React Table v7 gotcha — sticky columns declared outside a header group breaking layout — with an actionable error message rather than silent visual breakage.