Bitfield Docs

A slot is a named package target your product can ask Bitfield to run.

A screen has a button: “Find the next step.” The screen should not import the search code, the ranking code, the package setup, or the storage details. It should send a named request and handle the reply.

App

The app names a target and sends payload bytes.

→

Slot

The slot implementation owns how the work happens.

→

The app receives a reply without importing private setup.

A feature should be able to call named work without taking a dependency on the private code that performs it.The slot might answer a question, transform data, render a view, call another system, or do work in the background. The important part is the public call. The app calls the slot by name. The slot owns how it does the work.

Why slots exist

Without slots, features start importing each other’s implementation files. That feels simple at first. Then the product grows, and one feature directly depends on another feature’s storage layout, input names, failure handling, and release timing.Slots keep that from turning into every feature depending on every other feature. 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 target. App code can call that target without knowing the private implementation.

A slot has methods. Methods are the public actions the slot 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 importing another feature’s private code. That matters because private details change. Public slot names should stay steady.

Common mistakes

Mistake	Why it hurts	Better path
Importing the target implementation into the UI	The feature boundary collapses	Use `sendRequestToBitfieldTarget(...)`
Giving every feature a custom connection path	The product becomes hard to change	Use named targets and package files
Treating slots as storage records	A slot is a callable package target, not the stored data itself	Read Database and runtime
Hiding failure handling	Real target calls can fail	Read Send a request

Send an action request: Send a request
Declare a callable slot: Callable package slot
Look up request behavior: Runtime Kit API

​Why slots exist

​The model

​What the app sees

​What this prevents

​Common mistakes

​Next

Why slots exist

The model

What the app sees

What this prevents

Common mistakes

Next