Skip to content

Let the front-end declare which blocks board_ui paints - #350

Closed
nbenn wants to merge 1 commit into
mainfrom
349-ui-build-timing
Closed

nbenn wants to merge 1 commit into
mainfrom
349-ui-build-timing

Conversation

@nbenn

@nbenn nbenn commented Aug 27, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

  • The new initial_block_ids() generic is where a front-end declares which blocks board_ui() paints up front. The board method answers with every block, so core's own UI is unchanged; blockr.dock's answer moves out of its board_ui() method and into a one-line method of its own.
  • The board server seeds its build ledger from that same declaration, so the set is stated once rather than restated server-side. That ledger is the FALSE middle state of visible which Make visible a logical channel — is_visible should be isTRUE, not !is.na #306 introduced and nothing in core read until now: NA never built, FALSE built off screen, TRUE painted.
  • Reading the ledger back is the new built_block_ids(). A front-end that builds block UI lazily stops reconstructing it — blockr.dock inferred it from !is.na(visible) behind a private helper, and took a real bug (a blanked view on first visit) getting there off required first.
  • Core also marks a block built once insert_block_ui() has put it in the page, and marking is one-way, so nothing demotes a painted block back to unbuilt.

Breaking for a front-end that paints a subset of blocks without declaring it: the default method reports every block, so core enters blocks in the ledger whose UI was never built. Confirmed on blockr.dock, where a first visit to an off-screen view then short-circuits its card build and leaves the panels blank. The adoption is BristolMyersSquibb/blockr.dock#442, pinned below.

Not in scope: a core entry point for the deferred build itself. With dock#438 no front-end defers card builds, so such a verb would have no caller; what lands is the vocabulary that makes deferral expressible — declare a subset, insert the rest through insert_block_ui(), report built — with placement left to the front-end that owns its page structure.

BristolMyersSquibb/blockr.dock#442
BristolMyersSquibb/blockr.dag@core349-pin
BristolMyersSquibb/blockr.assistant@core349-pin

Fixes #349

Core hardcoded the initial block UI set as "every block" and each
front-end hardcoded its own answer inside its board_ui() method, so a
board could say how to insert a block's UI but not when it wanted that
UI to exist. The new initial_block_ids() generic is that declaration,
and the board server seeds the build ledger from it -- the FALSE middle
state of `visible`, which until now only a front-end wrote and nothing
in core read. Reading it back is built_block_ids(), so a front-end that
builds block UI lazily stops inferring the ledger off a channel named
for something else.
@codecov

codecov Bot commented Aug 27, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines Coverage Δ
R/block-server.R 96.64% <ø> (ø)
R/board-server.R 96.84% <100.00%> (+0.02%) ⬆️
R/board-ui.R 91.00% <100.00%> (+0.27%) ⬆️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@nbenn

nbenn commented Sep 28, 2026 •

Copy link
Copy Markdown
Collaborator Author

Closing as superseded by https://github.com/orgs/BristolMyersSquibb/discussions/489. The build ledger in visible leaves core, since a block's UI now exists whenever its server does (#317). A front-end's opening screen becomes its opening claim, declared when its callback is registered under #337's rework, and whether board_ui() paints it into the page is left to #317.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Lift block UI build timing into the front-end API

1 participant