react-powerplug: renderless containers for state you would rather not write

The problem react-powerplug solves

React components mix two jobs: holding state and drawing pixels. When you want a checkbox, a tab strip or a pagination control to be reusable, the drawing part is easy to lift out and the state part is not. You end up either duplicating the state logic in every place the widget is used, or writing a wrapper component that renders nothing and passes props down. React PowerPlug is the second option, packaged.

The README describes it as "a set of pluggable renderless components and helpers" that "provides different types of state and logic utilities that you can use with your dumb components." The intended reader is someone building a component library or a prototype who wants the state handled by a library and the markup handled by their own presentational components. The package.json description puts the same idea more bluntly: "Give life to your dumb components."

That framing matters, because it tells you where the library does not belong. It is not a state manager for application data, and it does not coordinate state between distant parts of a tree. It is a local container.

How the container passes state down

The mechanism is the render props pattern, and the README links to the React documentation page for it rather than explaining it at length. A PowerPlug component holds state internally and calls a function that you supply, passing the current state and the setters as an argument. Your function returns the JSX. The library never renders markup of its own.

The README's own examples show two spellings of the same idea. You can put the function as the child of the component, or pass it through a render prop:

import { State, Toggle } from 'react-powerplug'
import { Pagination, Tabs, Checkbox } from './MyDumbComponents'

<State initial={{ offset: 0, limit: 10, totalCount: 200 }}>
  {({ state, setState }) => (
    <Pagination {...state} onChange={(offset) => setState({ offset })} />
  )}
</State>

That block is copied from the README. State takes an initial value and hands back a state object plus setState, so a dumb Pagination component receives offset, limit and totalCount as ordinary props and reports changes upward through a callback. Toggle works the same way with on and toggle. Which components exist beyond State and Toggle is not listed in the README, so check the src/ directory before you plan around a specific one.

The package ships three build targets, which the package.json makes explicit: main points at dist/react-powerplug.cjs.js, module points at dist/react-powerplug.esm.js, and types points at types/index.d.ts. The README also claims the library is tree shaking friendly because the ESM build has no side effects, and puts the size at roughly 3kb. Those are the project's figures, not measurements.

Installing react-powerplug and wiring a first Toggle

The README gives two package manager commands and a UMD script tag. For a bundler-based project, either of these works:

yarn add react-powerplug

npm i react-powerplug

There is no configuration step, no provider to wrap your application in, and no peer dependency list in the README. After installing, import the container you need and render your own component inside it. The README's checkbox example is the shortest complete use:

import { Toggle } from 'react-powerplug'
import { Checkbox } from './MyDumbComponents'

<Toggle initial={true}>
  {({ on, toggle }) => (
    <Checkbox checked={on} onChange={toggle} />
  )}
</Toggle>

What you should see is a Checkbox that is checked on first render because initial is true, and that flips when the user interacts with it, with no state written in Checkbox itself. The same component accepts a render prop instead of children, as the README shows with initial={false} and render={({ on, toggle }) => ...}.

If you are not using a bundler, the README exposes a UMD build at https://unpkg.com/react-powerplug/dist/react-powerplug.min.js and states that it is exposed as ReactPowerPlug on the global scope. The README does not document which React versions that build expects.

Where react-powerplug stops being the right tool

The release history is the first limitation, and it is not a small one. The most recent published release in the repository is v1.0.0-rc.1 from 2018-07-02, after v1.0.0-rc.0 and v1.0.0-alpha.5 earlier that year. The last push to the repository was on 2026-03-08, so work has happened since, but no release has been cut since 2018. A release candidate that has sat unreleased for that long tells you the published artifact and the repository are not the same thing.

The second limitation is scope. A renderless container gives one subtree a piece of state. If two sibling components need to agree on the same value, you either lift the container above both of them or reach for a context-based solution. PowerPlug does not solve that problem, and the README does not claim it does.

The render prop shape is also a nesting tax. Three containers means three nested functions before you reach your markup, and the README's own examples already show two levels in a single snippet. React hooks, which arrived after this library's last release, express the same local state in one line inside the component that uses it. If you are on a modern React version and your state is genuinely local, a hook is less indirection for the same result. PowerPlug's advantage is that it works in class components and in React versions that predate hooks, and that the state logic lives outside your presentational component.

Alternatives and the difference in approach

The closest alternative is writing the container yourself. A component that calls useState and renders props.children as a function is roughly ten lines, and it is the same pattern the library packages. The trade is that you own it, you can shape the returned object to exactly what your component needs, and you do not depend on a package whose last release was in 2018. What you give up is the set of ready-made containers and the documentation site, so the decision comes down to how many of those containers you would otherwise write.

A different alternative is a context-based state library, which moves the state above the component tree instead of inside it. That approach handles sharing between distant components, which PowerPlug does not attempt. It also introduces a provider boundary and a subscription model, which is more machinery than a single checkbox needs. For one widget's local state, the context route is heavier; for cross-tree state, PowerPlug is the wrong shape entirely.

The honest summary is that react-powerplug sits between those two: lighter than a context store, more structured than a hand-written hook, and older than both.

Licence, maintenance and upgrade cost

The package is MIT licensed, and the LICENSE file sits at the repository root. MIT is permissive: you can use, modify and redistribute the code, including in closed-source products, provided the copyright notice and permission notice travel with it. That is a general description of the licence text, not legal advice, and if your organisation has rules about attribution in bundled dependencies, read the LICENSE file rather than this paragraph.

The maintenance picture is the part to weigh. The repository is not archived, and the last push was on 2026-03-08, so the codebase has seen activity recently. But the release list stops at v1.0.0-rc.1 from 2018-07-02. If you install from npm, you get whatever that release published, not whatever the repository contains today. The README does not document a rollback path, a migration guide between the alpha, rc and stable versions, or a support window.

The upgrade cost is therefore mostly a verification cost. Check that the component you want exists in src/, that types/index.d.ts compiles against your TypeScript version, and that the ESM or CJS build resolves correctly in your bundler. The repository carries both a .flowconfig and a types/ directory, so the project maintains Flow and TypeScript declarations in parallel, and the package.json scripts include typecheck:flow and typecheck:ts. Those scripts tell you the maintainers run both checks; they do not tell you the declarations are current.

Editorial conclusion

Adopt react-powerplug when you want state inside a dumb component without writing a class or a hook, and when the ~3kb footprint and zero dependencies matter more than a fresh release history. Do not adopt it as the state layer of a long-lived product: the newest published release is v1.0.0-rc.1 from 2018-07-02, so React 18 and 19 behaviour is not covered by any release note here. Before committing, check that the component you need exists in src/, that types/index.d.ts matches your TypeScript version, and that the UMD build at dist/react-powerplug.min.js still loads under your bundler.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. renatorib/react-powerplug on GitHub