Documentation / @etherfold/browser / reconfigureFromHotUpdate

Function: reconfigureFromHotUpdate()

reconfigureFromHotUpdate<ABI, ProcessResultType, ProcessorConfig>(indexer, generation, processorConfig?): Promise<ReconfigureReport>

Defined in: packages/browser/src/hotUpdate.ts:181

RECONFIGURE THIS TAB WITH THE PROCESSOR ITS OWN DEV SERVER JUST HANDED IT, so a handler edit keeps the warm fold instead of costing a page reload.

Call it from the application's own hot-update handler, with the module that handler receives:

if (import.meta.hot) {
  import.meta.hot.accept('./processor.js', async (module) => {
    if (!module) return;
    const next = module.tokenProcessor;
    const report = await reconfigureFromHotUpdate(indexer, {
      // ITS OWN store: a successor folds beside the incumbent, and two
      // generations sharing one database are one store.
      createState: async (context) =>
        openForWriting(
          await createBrowserStateStore(next.entities, {
            databaseName: `app-${context.stream}-${++saves}`,
          }),
        ),
      createProcessor: (state) => fromEntityProcessor(next)(state),
    });
    el('reload').textContent = messageFor(report);
  });
}

WHAT IT ANSWERS

ReconfigureReport (@etherfold/core), which is the SAME shape the admin upload route answers, because the arrivals are thin adapters in front of one call and a caller should branch on one contract rather than two (ADR-0085):

• registered -- the handler edit moved the identity, so a successor is folding beside the incumbent. The incumbent answered every read throughout and goes on answering until the promotion policy moves the pointer (on-catch-up by default; immediate is what a developer iterating usually wants, and is passed to createIndexerState).
• unchanged -- a hot update that genuinely changed nothing, which is RARE and TRUE. It is a SUCCESS, and the message says so plainly rather than leaving a developer wondering why their save did nothing.
• failed -- the processor could not be built, which in a dev loop is the ORDINARY case (a save mid-edit). Nothing was registered, and this indexer is exactly as it was: same generations, same pointer, still folding, still answering.

THE unchanged A DEVELOPER CAN STILL BE SURPRISED BY

The derivation is over handler SOURCE TEXT, so it does not MOVE for a change the text does not carry: an edited helper the handler imports, a changed entity declaration, or behaviour decided by a value the handler captured. Those really did change the fold, and this really will answer unchanged, so the message names them and names the way out. There is no {force} here and there cannot be: forcing means registering a generation BESIDE one of the same name, and a name is what a generation IS. indexer.updateProcessor(next, {force: true}) is the in-place verb for that case, and it costs the rebuild this call exists to avoid.

Type Parameters

ABI

ABI extends Abi

ProcessResultType

ProcessResultType

ProcessorConfig

ProcessorConfig = undefined

Parameters

indexer

HotUpdatableIndexer<ABI, ProcessResultType, ProcessorConfig>

generation

HotUpdateGeneration<ABI, ProcessResultType, ProcessorConfig>

processorConfig?

ProcessorConfig

Returns

Promise<ReconfigureReport>