Page properties: app wiring

Closed
  • Is something wrong?
#142 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #161 by @shovon — merged

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
58/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
desktop, full-stack

Research direction

Start with the existing block write path: pages-session.ts, pages-ipc.ts, src/shared/pages.ts, and src/preload/index.ts; trace how changes(...) resolves after onChanged receives state. Then carry the listed property commands through those layers and include properties from list(page) in PagesState.showing. Run the named session and store tests; done means property writes stay ordered with block writes and state includes properties for the listed page cases.

Written by the indexing model from the issue text.

Description

enhancement

Part of #84, on the app side. This connects the app to the properties domain model in @pbnotes/pages (#155): the writes go from the renderer through main to the package's commands, and a page's properties reach the renderer with the page. It adds no rules of its own: every check and every meaning is the package's (#132, #133), and this ticket only carries them.

Done when a view needs it, beside the table (#137). Nothing in @pbnotes/pages waits on it. Do #158 first: after it, a write in the app is a case on one Command union, not a channel of its own.

What already exists

  • After #132 and #133: the events, the fold, the reads, the builders and the commands, all in @pbnotes/pages. predict for property events is #137's.
  • After #158: every write in the app is a case on Command in src/shared/pages.ts, sent over pages:command through run on PagesApi, checked in pages-ipc.ts by its entry in the checker table, and run by the session's switch inside write.
  • PagesState.showing carries each page as { page, references }. Nothing about a page but its blocks reaches the renderer.

What it takes

  • Main: a switch case per command in the session's run, calling setProperty and the rest inside write, so they are recorded in order with the block writes.
  • IPC: one case per command on Command, and a checker per case in pages-ipc.ts, no new channels. Each checker checks the shape of what arrives (a target: { kind: "page", title } with the title through requireTitle, or { kind: "block", id }; a path as a string[]; a scalar) and builds the command fresh from the fields it reads, so nothing extra reaches the log: the builders write of as they are given it. The package's commands make the full checks; the checker only stops what isn't the right type from reaching them.
  • Preload and PagesApi: nothing new: run already resolves once onChanged has heard the state a command led to. Doc comments on each new Command case, as the block cases have.
  • PagesState: each entry in showing carries its page's properties as list(pages, { kind: "page", title }) returns them, as plain data that survives a structured clone. Nothing that reads blocks changes.

The commands are #133's: setProperty, unsetProperty, addPropertyItem, removePropertyItem, removeProperty and renameProperty.

Test

  • pages-session.test.ts: a property write is ordered with block writes sent around it, and the state it leads to shows it.
  • pages-store.test.ts: getState carries a page's properties, for a page with blocks, a page with properties and no blocks, and the journal.

Out of scope

  • Anything in @pbnotes/pages (#132, #133).
  • Block properties in PagesState: the commands take a block target, but nothing carries a block's properties to the renderer until a view needs them (#155 leaves the UI out).
  • The table and its story (#137), and keeping in-flight writes for predict, which is the table's.
Dominant language
TypeScript
Stars
0
Forks
1
Avg merge
10m
Merged PRs (30d)
57

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from shovon/pbnotes

All issues in shovon/pbnotes

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.