Appearance

Documentation / @etherfold/browser / IndexerHost

Type Alias: IndexerHost<ABI, ProcessResultType, ProcessorConfig> ​

IndexerHost<ABI, ProcessResultType, ProcessorConfig> = object

Defined in: packages/browser/src/host/serve.ts:209

What the entry point that obtained the port gets back.

Generic over what the entry's spec was, because one of its verbs takes CODE (reconfigureFromHotUpdate, a processor of this host's own ABI). The defaults are any so that a bare IndexerHost still names EVERY host, as it did before the verb existed: code that only starts, stops and disposes one need not spell its ABI, and a narrower default would refuse every host whose processor is typed.

Type Parameters ​

ABI ​

ABI extends Abi = any

ProcessResultType ​

ProcessResultType = any

ProcessorConfig ​

ProcessorConfig = any

Methods ​

dispose() ​

dispose(): void

Defined in: packages/browser/src/host/serve.ts:289

Stop driving and stop answering.

It does NOT close the endpoint: what owns the wire is whatever obtained it, and a worker that closed its own scope here would take the port down under a tab that is still holding it.

Returns ​

void

progress() ​

progress(): HostProgress

Defined in: packages/browser/src/host/serve.ts:211

How far the fold has got, as the port reports it. The same value the progress case answers.

Returns ​

HostProgress

reconfigureFromHotUpdate() ​

reconfigureFromHotUpdate(generation, processorConfig?): Promise<ReconfigureReport>

Defined in: packages/browser/src/host/serve.ts:278

TAKE THE PROCESSOR THIS WORKER'S OWN DEV SERVER JUST HANDED IT, folding it BESIDE the live generation: the guide's hot-reload axis one, where the fold runs in a worker.

Call it from the worker ENTRY's own import.meta.hot.accept(...) handler, with the module that handler receives. Under Vite a module worker is an HMR client in its own right, so the edited module arrives HERE, where the fold runs, and never has to cross a port (work/notes/findings/a-module-worker-receives-hmr-under-vite.md):

ts
const host = hostIndexerInThisWorker({createState, createProcessor, keepStream});
if (import.meta.hot) {
  let saves = 0;
  import.meta.hot.accept('./processor.js', (module) => {
    if (!module) return;
    const next = module.tokenProcessor;
    void host.reconfigureFromHotUpdate({
      // ITS OWN store: the successor folds beside the incumbent.
      createState: async (context, {signal}) =>
        openForWriting(
          await createBrowserStateStore(next.entities, {databaseName: `app-${context.stream}-${++saves}`}),
          {signal},
        ),
      createProcessor: (state) => fromEntityProcessor(next)(state),
    });
  });
}

It IS reconfigureFromHotUpdate (hotUpdate.ts), run against this host's container, so it answers the same three verdicts the main thread's does and for the same reasons: registered (the successor folds beside the incumbent, which answers every read until the promotion policy moves the pointer), unchanged (the handler sources are the fold already running) and failed (the save did not build, and the host is exactly as it was). The processor is built HERE, from the module this worker's own module graph received, so its identity is the module arrival's derivation over what this worker instantiated (ADR-0086) and nothing a tab computed.

It is a METHOD here where the main thread's is a free function, and the difference is what a tab needs: nobody on the tab's side made this call, so the host PUBLISHES the verdict (HostProgress.hotUpdate) and every tab it serves reads it off the progress push. It is serialised with a tab's reconfigure, as the main thread serialises its reconfiguring verbs.

A development path only: processorBundle and a production build never reach it, and this package still subscribes to nothing.

Parameters ​

generation ​

HotUpdateGeneration<ABI, ProcessResultType, ProcessorConfig>

processorConfig? ​

ProcessorConfig

Returns ​

Promise<ReconfigureReport>

startIndexing() ​

startIndexing(): Promise<HostProgress>

Defined in: packages/browser/src/host/serve.ts:221

START THE DRIVER. The same call the startIndexing case serves, so an entry point that wants to decide for itself has the verb its tab has.

Starting a driver that is already running changes nothing and answers where the fold is. One arriving while a STOP is being honoured waits for that stop to land and then starts afresh, so the two cannot race into a host that was asked to index and is not.

Returns ​

Promise<HostProgress>

stopIndexing() ​

stopIndexing(): Promise<HostProgress>

Defined in: packages/browser/src/host/serve.ts:227

STOP THE DRIVER, resolving once the cycle in flight has LANDED: no chain request is made after this resolves, and the cursor is where a completed cycle would have left it.

Returns ​

Promise<HostProgress>