Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.bitfield.so/llms.txt

Use this file to discover all available pages before exploring further.

Concept

​
Slots.

A slot is a named door to something your product can ask Bitfield to run.

That “something” might answer a question, transform data, render a view, call another system, or do work in the background. The important part is the shape. The app calls the slot by name. The slot owns how it does the work.

​
Why slots exist

Without slots, features start talking directly to each other. That feels simple at first. Then the product grows, and one feature needs to know how another feature stores data, names inputs, handles failures, and changes over time.Slots keep that from becoming a knot. A feature sends a request to a slot. The slot replies. The feature does not import the slot’s private code or copy its private rules.

​
The model

A slot has a name. The name is the public door. App code can ask for that door without knowing the room behind it.
A slot has methods. Methods are the public actions the door accepts, like a query or a command.
A slot has its own setup. The package decides how the slot runs. The app does not need those details.

​
What the app sees

The app-facing surface stays small:
await sendRequestToBitfieldTarget({
  target: 'product.search',
  payload: { query: 'camera' },
});
The app sends a target and payload. Bitfield gets that request to the right runnable piece and returns reply bytes.

​
What this prevents

Slots prevent feature code from learning too much about other feature code. That matters because private details change. Public doors should stay steady.
Last modified on May 8, 2026