Files
ng-eventually/examples/notebook
Sylvain Duchesne 2dc28966c7 T01.i: bring examples/notebook into the pnpm workspace, fix its type error
pnpm-workspace.yaml listed only packages/*, so pnpm never installed
examples/notebook's dependencies even though root package.json's
workspaces field named examples/* too; the example ran on a stray
node_modules a manual bun install had left behind (symlinks into
node_modules/.bun, including a dangling @ng-eventually/sdk link to a
package that no longer exists). Added examples/* to pnpm-workspace.yaml
and reinstalled; examples/notebook now resolves @ng-org/orm and
@ng-org/web to the exact same pnpm store instances packages/polyfill
uses (verified via the symlinks and node_modules/.pnpm listing) - no
package ended up duplicated.

That alone did not fix the example's TS2345: NoteShape's object
literal had its dataTypes[].valType widened from the "iri"/"string"
literals to plain string (no satisfies clause), which the existing
test suite already guards against elsewhere (satisfies
ShapeType<BaseType>). Applied the same pattern here, importing the
already re-exported ShapeType/BaseType from @ng-eventually/polyfill -
no new dependency needed, no compiler option touched.
2026-09-21 14:40:47 +02:00
..

Notebook — the library's example application

A minimal application written against @ng-eventually/polyfill, in plain DOM.

It exists for two reasons, and the second is the one that matters.

It shows how to use the library. Every call in app.ts is what a real consumer writes. There is no test scaffolding, no privileged import, no reaching into the library's internals — it resolves @ng-eventually/polyfill as an external consumer does. If something reads awkwardly here, it reads awkwardly for everyone.

It is what the applicative e2e suite drives (packages/polyfill/e2e/notebook.ts, bun run test:e2e:app). The other suite talks to a bag of methods on window.__sdk, which proves the functions run but never that an application can be written with them — and that gap shipped a real defect once: a document's inbox was green in tests and unusable in practice, because the harness handed an address across an identity boundary through a variable, something no application can do. Here each identity is its own browser page, and the only values that cross between them are the ones that cross in life: a note's reference, copied off one screen, and an identifier typed into a field.

It has already paid for itself: writing it surfaced that the then-published readUnion's property bags returned string where the values are always document references (so a consumer had to cast whatever it had just read before passing it back), and that the access gate normalized what a user typed but not what the URL carried.

What it exercises

Signing in, writing notes by scope, listing one's own, reading a note from its bare reference, handing a reader the key to a protected note, opening a note for messages, leaving a message on someone else's note, and reacting to changes.

The four journeys the suite runs, and what each proves:

Journey What it proves
Bob reads Alice's PUBLIC note from its reference alone A public store serves its notes' keys — a bare reference is enough, and no key ever crosses
Alice's PROTECTED note stays shut until she shares it The same gesture, the opposite outcome, decided by where the note sits and not by what was sent
Bob leaves a message on Alice's note, and only Alice reads it A depositor FINDS the address from the note itself; depositing grants no reading
Each actor's list holds their own notes The boundary, seen from the only place that matters: the screen

It has also found three defects of its own, each one the harness could not see. The first turned out to be a LIBRARY defect rather than an application one: the connection work had to be awaited at sign-in, or a note just shared with you read as unreadable — so ensureIdentity now awaits it, and connectedUser left the published surface. The other two were the application's: a stale answer stayed on screen beside a fresh question, and changing the scope did not refresh the list.

Running it

cd packages/polyfill && bun run test:e2e:app builds it, serves it, and drives it against the real broker. To open it by hand you need a wallet: serve the folder with a bundled app.js and a /shared-wallet.ngw, and set __NOTEBOOK_WALLET_PASSWORD__.