Reorder elements in a reactiveValues() object

[nbenn]

Thanks to #3774, ordering of elements in a reactiveValues() object is fixed to the insertion order. In an application of mine, I need the ability to reorder elements. As there is no way to remove an element, the only way I could find to get me what I need was to fiddle with internals. Something along the lines of

reorder_rv <- function(x, new) {

  stopifnot(
    setequal(new, names(x)), anyDuplicated(new) == 0L
  )

  internals <- .subset2(x, "impl")
  internals$.nameOrder <- new

  invisible(x)
}

While I appreciate that it might not be a very common problem I'm trying to get around here I nevertheless wanted to raise the issue here and ask whether you're open to providing such functionality as part of the "public" API.

[gadenbuie]

In an application of mine, I need the ability to reorder elements.

Can you describe why you need to reorder elements?

[nbenn]

Sure, happy to elaborate. I hope I can simplify enough without leaving out key aspects. The scenario is roughly as follows:

• We have a parent module where the user can choose different "data inputs".
• In a child module these "data inputs" are used to "compute a result".

For example base::merge(): This "computation" has two "data inputs" that are known up front, x and y, and this can be passed as list of two reactiveVal() objects to the child module. In the parent module, the user can then select data to be used as x and y "arguments" and we have reactivity that propagates changes to the child module.

Another example base::rbind(): In the parent module, now an arbitrary number of data inputs can be selected. This set of inputs has to be passed as reactiveValues() object in order for length changes to propagate to the child module.

Things that are not straightforward with a reactiveValues() object, but are relevant for the above scenario (where the reactive object in some sense of represents the args argument of a do.call() call):

• Unnamed elements: This corresponds to unnamed "arguments" in our scenario and the workaround is to simply use "special" names such as "...1", "...2", etc. and disallow explicit use of these names.
• Reordering of elements: The user might first select two inputs in our rbind example, but then decide to insert a third in the middle.
• Removing elements: In the rbind example, this present less of an issue as a NULL assignment to an element effectively removes that element from the result.

Removal of elements is tracked in #2439. Here I'm trying to make a case for reordering also being a manipulation for reactiveValues() objects that could be considered.