Documentation / @etherfold/browser / createPortReadSurface
Function: createPortReadSurface() ​
createPortReadSurface<
D>(port,declarations):ReadSurface<StateStore,D>
Defined in: packages/browser/src/host/reads.ts:118
GENERATE THE READ SURFACE OF A SET OF DECLARATIONS OVER A PORT.
The port-side twin of createReadSurface, with the same call shape, the same result TYPE, the same four reads per entity and the same collection per declared relation on its parent:
const indexer = connectToIndexerHost(dedicatedWorkerHost(worker));
const reads = createPortReadSurface(indexer, myProcessor.entities);
const token = await reads.token.getCurrent({id: '1'}); // {id: string; owner: string | null}The as-of address is a block NUMBER, which is what the seam takes: addressing by hash or by time is a read layer a BACKEND adds above the seam, and a host that has one is not reachable from here -- a port speaks the seam, so the surface a tab holds is the seam's.
The declarations are CHECKED against the host, on the first read ​
createReadSurface compares its declarations with the store's at CONSTRUCTION and refuses a disagreement naming both, because a surface generated from a stale copy types its rows off columns the store does not have and projects them to null -- a plausible wrong answer. That question cannot be asked synchronously across a port, so it is asked ONCE, as soon as this is called, and every read awaits the answer: the refusal lands on the first read instead of on the constructor, in the same words, by the same rule (assertDeclaredBy). It is not re-asked afterwards; a host's declarations do not change under a tab, because both ends come out of one build.
Type Parameters ​
D ​
D extends readonly EntityDeclaration[]
Parameters ​
port ​
declarations ​
D