# react-fns: Browser APIs as React Components and HOCs

> react-fns wraps imperative browser APIs in declarative React components and higher-order components. The package installs from npm, ships TypeScript types, and has not been pushed to since 2018-02-05.

**jaredpalmer/react-fns** — GitHub describes it as Browser API's turned into declarative React components and HoC's. The repository metadata lists TypeScript as its primary language. The metadata lists the MIT license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/jaredpalmer/react-fns
- Stars: 3,700 · Forks: 98
- Language: TypeScript
- License: MIT
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/jaredpalmer-react-fns

## The problem react-fns addresses: browser APIs are imperative

Browser APIs are event-driven and stateful. A component that needs the current window width, an online/offline flag, or a scroll position has to register a listener on mount, store the value in state, update it on every event, and remove the listener on unmount. That is the same shape of code in every component that needs it, and the cleanup is easy to forget.

react-fns is a collection of those APIs turned into declarative React components and higher-order components. Instead of writing the subscribe and unsubscribe cycle by hand, you render a component and read the value from its render prop or props. The package description in package.json calls it "Modern React components, hoc's, and utilities functions." The README describes it as "a collection of imperative Browser API's turned into declarative React components and higher-order components for lots of common situations."

It is aimed at React application developers, not library authors or framework builders. The keywords in package.json are react, react-fns, render-props and hoc, which tells you the intended consumption pattern: you compose these into your own components rather than extending them.

## How the render-prop and HOC mechanism works

Two consumption patterns are named in the package metadata. The first is the render prop: the component owns the browser API subscription and calls a function you pass as a child or prop, handing you the current value. Your render function decides what to draw. The second is the higher-order component: a function that takes your component and returns a new one with the browser value injected as props. Same subscription logic, different composition style.

The repository layout supports this. src/ holds the TypeScript sources, rollup.config.js drives the bundle, and tsconfig.json configures compilation. The build script runs tsc first, then Rollup twice, once with NODE_ENV=production and once with NODE_ENV=development, and finally removes the compiled directory. That produces the three entry points declared in package.json: main points at dist/index.js, module at dist/index.es6.js, and types at dist/index.d.ts. So consumers get a CommonJS build, an ES module build, and type definitions.

One detail worth noticing is sideEffects: false in package.json. That is a signal to bundlers that importing the package does not run observable top-level code, which allows tree shaking. Whether every component in the collection is actually free of side effects is not something the README states, and the package.json shown here has no peerDependencies block, so the React version the package expects is not visible.

## Installing react-fns and rendering a first component

The README gives a single install command. It is a normal npm dependency, not a global tool.

```bash
npm i react-fns --save
```

After that, import the component you need from the package root and render it. The README points to a separate API Reference at react-fns.netlify.com/docs/en/api.html for the list of components and their props; the README itself does not enumerate them, so check that page or the src/ directory for the exact export names before writing imports. The shape of a render-prop call site is a component whose children are a function, and the function receives the value the component tracks. Replace the placeholder component name with a real export from the API reference.

Because the package ships dist/index.d.ts, an editor with TypeScript support will autocomplete the available exports once the package is installed, which is the fastest way to see what is actually in the build.

The README also lists a Community Discord invite for questions. There is no homepage field in package.json pointing at the website; the repository README carries the link instead.

## Where react-fns stops being the right tool

The most concrete limitation is time. The last push to the repository was on 2018-02-05, and the most recent release listed is v1.4.0 on the same date. The repository is not archived, but nothing here suggests ongoing work, and the devDependencies pin react and react-dom at ^15.6.1 with @types/react at 16.0.2. A package built and tested against React 15 and early React 16 typings is not a safe default for a codebase on a current React release.

The second limitation is scope. These are wrappers around browser APIs, which means they inherit browser behaviour. Anything that depends on a listener has the usual failure modes: an API that never fires in a given environment, a value that is unavailable during server-side rendering, or a subscription that fires more often than your render can absorb. The README does not document rollback, SSR behaviour, or how each component behaves when the underlying API is missing, so those questions have to be answered by reading src/ or by testing in your own environment.

The third is that this is a convenience layer, not a capability layer. If you need one browser value in one component, a useEffect hook with addEventListener and a cleanup function is a few lines and adds no dependency. react-fns pays off when you want the same subscription pattern across several components and prefer a declarative call site over repeated effect code.

## Alternatives and the difference in approach

The obvious alternative is writing the hooks yourself. React's own effect model gives you the same subscribe, store, cleanup cycle in a custom hook, and you control exactly which events you listen to and when you re-render. The difference is not capability; it is where the code lives. With react-fns, the subscription is inside a component you import, and your call site is declarative. With a custom hook, the subscription is code you own and can adapt to your rendering strategy, batching rules, or SSR constraints. Given that react-fns predates the hooks era, a hook-based approach is also the one that will keep working as React evolves.

A second option is a general-purpose hooks collection from the same era or later, which typically covers a much wider set of browser and DOM behaviours under one dependency. The trade-off is dependency size and API surface: a broad collection gives you more than you need, while react-fns is narrow and focused on the browser API wrappers it names. If you only need one or two of these behaviours, a small custom hook is less to carry than either option.

## Maintenance cost, licence, and what to check before upgrading

The licence is MIT, declared in package.json and present as a LICENSE file at the repository root. MIT permits use, modification and redistribution with the licence and copyright notice retained. That is the extent of what can be said here; whether a given use is compatible with your organisation's policy is a question for your own review, not something the repository answers.

Upgrade cost is the practical concern. There are two releases listed, v1.2.0 on 2017-11-17 and v1.4.0 on 2018-02-05, and no release after that. If you adopt the package, you are adopting a frozen version, and any fix you need has to come from a fork or a patch. The build toolchain in package.json is also dated: Jest 20, husky 0.14, lint-staged 5, prettier 1.10. Running npm run build on a modern Node version is not something the repository confirms will work, and the README does not document a supported Node version.

Before upgrading anything, check the peer expectations in package.json against your installed React, and read src/ to confirm which components exist in the version you are on. The README does not include a changelog, so the difference between v1.2.0 and v1.4.0 is not documented.

## Conclusion

react-fns suits teams maintaining an older React 15 or 16 codebase that already depends on it, or anyone who wants a small, readable reference for wrapping a browser API in a render-prop component. It does not suit new projects that need current React support, since the last push was on 2018-02-05 and devDependencies pin react and react-dom at ^15.6.1. Before adopting, verify two things in the repository: which components exist under src/, and whether your React version matches the peer expectations in package.json. The package itself is a frozen artifact, not a maintained library.

## FAQ

### What is react-fns?

It is a collection of imperative browser APIs turned into declarative React components and higher-order components, per the README. It ships as an npm package with CommonJS, ES module and TypeScript type builds.

### Is react-fns frontend or backend?

Frontend. The package wraps browser APIs and is consumed inside React components, and its keywords in package.json are react, react-fns, render-props and hoc.

### How do I install react-fns?

The README gives one command: npm i react-fns --save. It installs as a regular dependency, and the package then exposes dist/index.js, dist/index.es6.js and dist/index.d.ts.

## Sources

- [Official README](https://github.com/jaredpalmer/react-fns#readme)
- [Project repository](https://github.com/jaredpalmer/react-fns)
- [Release notes](https://github.com/jaredpalmer/react-fns/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jaredpalmer-react-fns