Replace `trim_rv()` and the internal `reactives` class with the reactives package

[nbenn]

Two workarounds in blockr.core are now covered by the reactives package, which grew out of #227 and #244:

• trim_rv() removes keys from a reactiveValues() object through shiny's internals. destroy_link() uses it on the per-block routing in rv$sources[[id]] (created here), and it is exported because blockr.dock uses it too.
• The internal reactives class holds the variadic ...args (created here).

With the package:

• The routing in rv$sources[[id]] becomes a reactives::reactive_vals() collection. Removing a variadic link is src[[id]] <- NULL, and reading a key returns its reactiveVal() or NULL, which upstream_result() calls when present. The reactiveValuesToList(srcs) calls in block_inputs_ready() and block_server() (L354, L447) read the values of all slots instead, which Add helpers for bulk reads, type checks and tests nbenn/reactives#7 plans a helper for.
• The variadic ...args becomes a reactives::reactives() collection. Since as.list() returns the slots' reactives, dot_arg_values() calls each one, while block servers keep using names() and length(). The copies of dot_arg_values() in blockr.io and blockr.dm already call elements that are reactives.
• The environment of per-block reactiveVal()s in rv$needed_slots, and rv$eval, where removing a block leaves a NULL key behind, can move to collections as well.
• The trim_rv() export can be deprecated once blockr.dock no longer uses it.

Tests in blockr.dm, blockr.dplyr, blockr.ggplot and blockr.io build ...args with blockr.core:::reactives() and blockr.core:::append_reactive(), often with plain functions such as function() df1. They would switch to reactives::reactives(), with each slot wrapped in reactive(), since the package only accepts reactives.

This needs a CRAN release of reactives first, since blockr.core is on CRAN. It should also follow nbenn/reactives#4, which creates each key's cell in the session that owns the collection, because blockr.core destroys a block's module session when the block is removed.

[nbenn]

This is a work item of https://github.com/orgs/BristolMyersSquibb/discussions/489, where core's per-block state collection (#365) builds on it. It is not blocked by a CRAN release of reactives.

[nbenn]

I ported core onto reactives (68c67c8) along this plan in a local spike, moving rv$eval and rv$needed_slots to collections as well. Core's suite passes on the port, apart from the contract test below and a test of upstream_result() that builds its src_rv as reactiveValues(). The suites of blockr.dm, blockr.dplyr, blockr.ggplot and blockr.io show no new failures once their fixtures build ...args with the package and dot_arg_values() keeps the reactiveValues() branch described below. The plan needs four additions.

The variadic contract changes. The docs of new_block() promise that ...args "mirrors shiny::reactiveValues() for reads (names(), [[, $ and as.list()), and accessing a slot yields the value of its (lazily evaluated) input" (block-class.R#L39-L43), and a test has pinned that since 80338b5. A collection's reads return the slot's reactive instead, so that test fails on the port. The package settled on such reads in nbenn/reactives#2, on the premise that variadic blocks only read names() and length(). That holds for the blocks in our packages, whose other reads go through helpers that call any reactive they get, but three cynkra blocks index ...args for values: blockr.outline, whose comment relies on the active binding, blockr.seasonal and blockr.ts. They would receive a reactive where they expect data, and nothing errors: the req(is.data.frame(d)) in blockr.seasonal stalls instead. Would it be worth keeping the contract by handing block servers a read-only view of the collection, whose [[, $ and as.list() call the slot, while core's own reads use slot_values()? That also covers blockr.io's write block, whose status observer calls dot_arg_values(...args) only to depend on every slot's value. An observer making that call re-ran after an upstream data change on current core, and did not on the port.

CRAN versions pass reactiveValues() as ...args. The tests of blockr.dplyr 0.1.0 (test-bind.R#L21) and blockr.io 0.1.0 (test-write-block-server.R#L21) feed ...args = reactiveValues(...) to block_server(), as blockr.dm's tests still do (test-dm-block.R#L95). The current dot_arg_values() reads that through as.list(), while slot_values() rejects it with "Expected a reactives object.", which would fail both packages in the reverse-dependency checks of the core release. A reactiveValues() branch in dot_arg_values() keeps them working: core's rbind block, fed that way, returns 4 rows on current core, errors on the port, and returns 4 rows again with the branch, which also brings blockr.dm's four such tests back. I did not run the two CRAN suites themselves, since they import shinyAce and arrow, which the machine lacks.

The class has to leave core in the release that imports reactives. CRAN blockr.core 0.1.3 registers twelve S3 methods on the class reactives (NAMESPACE). In a session that loads both, the package loaded second overwrites the other's methods, and the collections of the first stop working. With core's main, $ on a core ...args fails with "use of NULL environment is defunct" when reactives loads second, and $ on a package collection fails with "using 'as.environment(NULL)' is defunct" when core loads second. Every package that imports reactives, blockr.dock with BristolMyersSquibb/blockr.dock#477 among them, therefore has to require the core release that drops the class.

Downstream fixtures break when this merges. The packages blockr.dm, blockr.dplyr, blockr.ggplot and blockr.io install core from main through Remotes:, and their tests build ...args with blockr.core:::reactives() and blockr.core:::append_reactive(). They cannot move to reactives::reactives() before the merge, because loading it next to current core runs into the clash above, so each needs a small PR right after this lands. In the spike, the fixtures became reactives::reactives() with each plain function wrapped in reactive(), or reactives::reactive_vals() where they hold values.

Notes for implementers

• A collection only takes reactives, so add_eval_slots() can no longer bind unbuilt_status, a plain function. One reactive() placeholder bound to every id works.
• Reads of a collection subscribe, and reads of a plain environment do not. Once rv$needed_slots is a reactive_vals() collection, the reads in block_needed_slot() and set_needed_slot() need isolate(), or a reader that creates its own slot invalidates itself. The same goes for the length() that sync_dot_args() appends with (Appending a slot as documented re-runs the observer that appends nbenn/reactives#57).
• Emptying ...args in sync_dot_args() goes by position, with args[[1L]] <- NULL, since unnamed slots have no name to remove them by.
• The internal snapshot_reactives() in R/utils-tests.R shares its name with the package's export, and needs a branch that hands collections to reactives::snapshot_reactives().
• Writing a value into a reactive_vals() slot that may not exist yet, as setup_link() and set_needed_slot() do, takes a check and either a new reactiveVal() or a write through the old one. The package has no call for that yet (Write a value to a slot by key, creating its reactiveVal() in the collection's session nbenn/reactives#56), and a reactiveVal() created that way belongs to whichever module creates it, which matters for Add a per-block state collection that follows the board's blocks #365.

[nbenn]

Decided: block servers receive the collection itself, so reading a slot of ...args returns its reactive, the way fixed data inputs already arrive. The description of ...args in ?new_block, NEWS and the test from 80338b5 change with it, and dot_arg_values() keeps its reactiveValues() branch for the CRAN reverse dependencies.

The blocks that read slot values directly are tracked in their own repos. Each issue carries a change that works with both versions of core, so it can land before this does:

• The write block's status observer in blockr.io: Keep the write block's status dependent on its data once ...args holds reactives blockr.io#45
• The template block in blockr.topline, whose reactiveValuesToList(...args) already fails on the current ...args: BristolMyersSquibb/blockr.topline#30
• The triage block in blockr.seasonal: Call the ...args slots in the triage block, which blockr.core will pass as reactives cynkra/blockr.seasonal#1
• The slide block in blockr.outline: Call the ...args slots in the slide block, which blockr.core will pass as reactives cynkra/blockr.outline#6
• The ts_arg_value() helper in blockr.ts: Call the ...args slot in ts_arg_value(), which blockr.core will pass as a reactive cynkra/blockr.ts#1