interior: copy-paste micro-interactions for React, built for the half-second after a click

The problem interior targets: the half-second after a click

The README opens with a claim that is easy to dismiss and hard to argue with: everybody builds these components, almost nobody finishes them. The unfinished part is named explicitly as three things, a jump, a restart, and an animation that ignores the person watching it. A button that resizes when its label changes, a list that jumps as it loads, a drag that gets stuck because the tab lost focus. The README's position is that none of these are bugs anyone files, but each one teaches the user to trust the interface less.

So the audience is narrow and specific. This is not for someone assembling a marketing page from a themed kit. It is for a team that already has a design language and is tired of re-solving the same interaction details: reserving space for a state before it arrives, making an interrupted animation restart cleanly, wiring a second complete keyboard path, and honouring prefers-reduced-motion without dropping the information the motion was carrying. The README states that under prefers-reduced-motion the information still arrives and only the trip is skipped. That is a design position, not a feature list, and it is the clearest statement of who the project is for.

No package: how the hook and the styled component split works

The distribution model is the first thing to understand, because it changes how you upgrade. There is no package. Every component is one file under components/interior/ that you copy into your own project. Each file exports two things: a headless hook named useX that owns all the behaviour and touches zero class names, and a styled component named X built on that hook, described in the README as an example you can keep or replace.

The consequence is that the behaviour and the appearance are separable by construction. Because the hook carries no class names, reskinning a component to your own design language costs only classes. That is a real architectural decision rather than a packaging detail, and it is the reason the copy step is defensible: you are not vendoring a black box, you are vendoring a file whose logic half you can leave untouched while rewriting the presentational half. The only dependency is motion.

What the README does not describe is what happens when the upstream file changes. There is no documented diffing process, no codemod, and no version marker inside the copied file. Once you copy, you own it, and the repository's own version field (0.1.0, and marked private) belongs to the docs site, not to a published library.

Running the docs site locally

The README gives two commands for the documentation site, and they assume bun. From the repository root, install and start the dev server:

bun install
bun run dev

The package.json confirms the dev script maps to next dev, so you should see the Next.js dev server start and the docs app become available. The repository layout backs this up: app/, components/, lib/, public/, next.config.ts, postcss.config.mjs and tsconfig.json are all present at the top level, which is the shape of a Next.js App Router project. The design rationale behind the components is documented separately in DESIGN.md.

If you want to check the repository before copying anything out of it, the package.json also exposes a combined check script:

bun run check

That runs oxlint and then tsc --noEmit, so it type-checks without emitting output. This is the docs repository's own tooling, not something you inherit by copying a component file.

Using a component in your own project

Because there is no package, the first real use is a copy, not an install. The README states that each component lives in components/interior/ and exports a hook and a styled component. So the workflow is: open that directory in the repository, pick the file for the interaction you want, copy it into your project, and make sure motion is available as a dependency, since the README names it as the only one.

Your import then points at the file you copied rather than at a package name. The README does not print an import statement, so there is nothing to copy verbatim here: the file you copied exports a useX hook and an X component from the same module, and your import has to match whatever path you placed the file at. Keep the styled component if it matches your design language, or drop it and call the hook directly from your own markup. The README's framing is that the styled component is an example you can keep or replace, and that behaviour lives entirely in the hook. What you should verify for yourself is the part the README asserts but does not demonstrate in the text: that the keyboard path is a complete second implementation and that prefers-reduced-motion keeps the information while skipping the trip.

Where interior is the wrong tool

The copy-in model is the limitation, and it is a real one. If your organisation requires dependencies to be versioned, reviewed and updated through a package manager, interior does not fit that process at all. There is no package to depend on, so there is no lockfile entry, no semver range, and no automated way to pull in a fix. The README does not document rollback, and no releases were retrieved, so there is no changelog to read before you copy a newer version of a file.

There is a second boundary. The project is React and TypeScript, and the only dependency is motion, which is a React-oriented animation library. If your application is not React, or if you have deliberately standardised on CSS-only transitions to keep the JavaScript bundle small, copying these files pulls in motion and a React component tree for behaviour you may already handle in a stylesheet.

Third, the scope is deliberately narrow. This is the half-second after a click, not page transitions, not scroll choreography, not a general animation toolkit. If you need a broad motion system with timelines and orchestration, you are looking at the wrong layer, and you would end up using motion directly anyway.

How this differs from a themed component library

The obvious alternative is a component library that ships prebuilt, themed components as an npm dependency. The difference is not quality, it is where the boundary sits. A library gives you the component and its appearance together, versioned, with a release process behind it. You import it, you upgrade it with a package manager, and you accept its design decisions or override them through props and theme tokens.

interior inverts that. It gives you the file, and it separates the behaviour from the appearance inside that file, so the behaviour is the part you keep and the appearance is the part you are expected to rewrite. You get no upgrade path and no release cadence, and in exchange you get a component whose every line you can read and change without fighting a theme API or a specificity war.

That trade only makes sense if you already have a design language and the interaction details are what you keep re-solving. If you do not have a design language, the styled components are the reason to look, and then you are effectively using interior as a library without the library's upgrade machinery, which is the worst of both arrangements.

Maintenance, licence and what a copy actually commits you to

The repository is not archived, and the last push was on 2026-09-10, so the project is being touched recently. That says nothing about the copied files in your tree, which will not move unless you move them. Treat every copied component as first-party code from the moment it lands: it is yours to review, test and fix, and no upstream commit will reach it.

The licence is MIT, which is permissive and permits use, modification and redistribution provided the copyright notice and permission notice are included. That is the licence text's own condition, not legal advice, and if you are redistributing the files inside a product you should confirm with your own counsel how the notice is carried. The repository also carries CONTRIBUTING.md and CODE_OF_CONDUCT.md, so the project has a stated contribution process, but that process governs the repository, not your copy.

Editorial conclusion

Adopt interior if your team already writes its own design system and wants finished interaction behaviour, not a themed component library: the hook/styled split means reskinning costs only classes. Do not adopt it if you need a versioned npm dependency, a changelog and a release cadence, because the README describes no package and no release notes were retrieved. Before copying anything, open components/interior/, confirm the useX hook and its styled X counterpart are both present in the file you want, check that motion is already in your dependency tree, and test the component under prefers-reduced-motion and with the keyboard, since the README claims both paths are complete implementations and that is the claim worth verifying first.

Frequently asked questions

Official sources

1. ddoemonn/interior on GitHub
2. Issues
3. License: MIT
4. Project website
5. README