Speed fixes from the integration branch: section key, controls test, parked cards

[christophsax]

@nbenn, these come from the integration branch (integration/devmaster-latest), where we have been trying out speed fixes on a demo board with about 90 blocks and ten views. The integration board feels noticeably snappier, and these are the dock parts of that, rebased onto main. They do not depend on the design-system PRs. Take what is useful; the three commits are independent, so dropping or splitting any of them is fine.

• Read the card's section key under isolate() (R/plugin-block.R). reported_sections() tested "collapse_blk_sections" %in% names(input). names() on a module's input depends on the session's whole input name set, so every new input anywhere on the board invalidated every block's visible, and freeze_hidden_inputs() re-read all of them per card mount: 21 to 43 runs over ~90 blocks on a first view visit, 1.2 to 6 s. After: 9 to 16 runs, 0.3 to 0.9 s. The unconditional read of input$collapse_blk_sections above it already takes the dependency that fires when the key first appears.
• Test a block for controls without resolving their dependencies (R/block-ui.R). has_expr_ui() only needs to know whether the expression UI renders any markup. doRenderTags() gives the same markup as renderTags() without resolving the html dependencies, which cost more than the markup once every control carried its own set: resolveDependencies 1.4 to 0.8 s over a short session.
• Stop styling and laying out parked cards (blockr-dock.css). The offcanvas pools that hold cards and extensions of views not on screen were only visibility: hidden, so the browser kept styling and laying out every parked card: half the document once all views have been visited. content-visibility: hidden on the closed pool skips that work. Unlike display: none, sizes stay readable, so Shiny does not suspend the outputs and charts get no resize to zero. One DOM insertion 106 to 11 ms, style per return view switch 2.1 to 0.8 s.

Not included:

• The largest single win is in blockr.ui: Shiny 1.14 sends an empty input message after every deferred input, and the server runs a full input cycle for each, so the dock's initialized report waits 2 to 4 s behind them on a first view visit. Filed as InputBatchSender sends an empty input message for every deferred setInput() rstudio/shiny#4436, worked around in Skip the empty input messages Shiny sends after deferred inputs blockr.ui#73. Attaching it in the dock is one line in blockr_app_ui.dock_board(), for after that merges.
• ~~A fix in core that is still open for discussion: has_required() stopping at the first declared slot (render gates read ~90 slots each).~~ Resolved in core by Fold front-end demand into the one multi-owner claim set blockr.core#337: a render gate now reads the one gate reactive.

Together with the blockr.ui change and two small ones in other packages, a scripted session on the demo board went from 37 to 30 s; the first visits to the larger views from 6.9 to 4.9 s and from 8.3 to 6.2 s. All numbers are from a shared container under load, so compare the arms of one measurement rather than across them.

The dock tests pass (8300) against blockr.core, blockr.ui and dockViewR main.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
R/block-ui.R	98.44% <100.00%> (ø)
R/plugin-block.R	99.57% <100.00%> (ø)

🚀 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]

Lgtm, thanks!