Conversation
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 Report✅ All modified and coverable lines are covered by tests.
🚀 New features to boost your workflow:
|
Collaborator
Author
|
Closing as superseded by https://github.com/orgs/BristolMyersSquibb/discussions/489. The build ledger in |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
initial_block_ids()generic is where a front-end declares which blocksboard_ui()paints up front. Theboardmethod answers with every block, so core's own UI is unchanged; blockr.dock's answer moves out of itsboard_ui()method and into a one-line method of its own.FALSEmiddle state ofvisiblewhich Makevisiblea logical channel —is_visibleshould beisTRUE, not!is.na#306 introduced and nothing in core read until now:NAnever built,FALSEbuilt off screen,TRUEpainted.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 offrequiredfirst.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.Fixes #349