Fix bug which prevented multiple outputs in callbacks returning Dash components in R

[rpkyle]

This PR proposes a minor modification to the way Dash for R's _dash-update-component handler resolves multiple outputs in callbacks which return one or more Dash components. This bug was discovered accidentally while fixing another bug in the Dash for R docs.

Previously, updatable_outputs implicitly assumed output_value's elements were members of only one class, since the specified return type of vapply was character(1):

dashR/R/dash.R

Lines 477 to 478 in b3be88d

	updatable_outputs<-"no_update"!= vapply(output_value, class, character(1))
	output_value<-output_value[updatable_outputs]

This was insufficiently robust, since valid return values from Dash callbacks can be objects in R which are members of more than one class.

As an example, if a callback returns list(htmlDiv(), ""), the class membership of its elements would be

> lapply(list(htmlDiv(), ""), class)
[[1]]
[1] "dash_component" "list" [[2]]
[1] "character"

The original definition of updatable_outputs would essentially attempt vapply(list(htmlDiv(), ""), class, character(1)) which produces the cryptic error

Error in vapply(list(htmlDiv(), ""), class, character(1)) : values must be length 1,
but FUN(X[[1]]) result is length 2

By rewriting the original line as

updatable_outputs <- vapply(output_value, function(x) !("no_update" %in% class(x)), logical(1))

class membership is inspected more flexibly, and a logical result is returned in the vapply step instead of a character vector of class names.

[rpkyle]

@alexcjohnson test for callbacks returning components added in eea0b46.

[alexcjohnson]

Perfect! 💃

[rpkyle]

This PR proposes a minor modification to the way Dash for R's _dash-update-component handler resolves multiple outputs in callbacks which return one or more Dash components. This bug was discovered accidentally while fixing another bug in the Dash for R docs.

Previously, updatable_outputs implicitly assumed output_value's elements were members of only one class, since the specified return type of vapply was character(1):

dashR/R/dash.R

Lines 477 to 478 in b3be88d

	updatable_outputs<-"no_update"!= vapply(output_value, class, character(1))
	output_value<-output_value[updatable_outputs]

This was insufficiently robust, since valid return values from Dash callbacks can be objects in R which are members of more than one class.

As an example, if a callback returns list(htmlDiv(), ""), the class membership of its elements would be

> lapply(list(htmlDiv(), ""), class)
[[1]]
[1] "dash_component" "list" [[2]]
[1] "character"

The original definition of updatable_outputs would essentially attempt vapply(list(htmlDiv(), ""), class, character(1)) which produces the cryptic error

Error in vapply(list(htmlDiv(), ""), class, character(1)) : values must be length 1,
but FUN(X[[1]]) result is length 2

By rewriting the original line as

updatable_outputs <- vapply(output_value, function(x) !("no_update" %in% class(x)), logical(1))

class membership is inspected more flexibly, and a logical result is returned in the vapply step instead of a character vector of class names.

[rpkyle]

@alexcjohnson test for callbacks returning components added in eea0b46.

[alexcjohnson]

Perfect! 💃

[rpkyle]

This PR proposes a minor modification to the way Dash for R's _dash-update-component handler resolves multiple outputs in callbacks which return one or more Dash components. This bug was discovered accidentally while fixing another bug in the Dash for R docs.

Previously, updatable_outputs implicitly assumed output_value's elements were members of only one class, since the specified return type of vapply was character(1):

dashR/R/dash.R

Lines 477 to 478 in b3be88d

	updatable_outputs<-"no_update"!= vapply(output_value, class, character(1))
	output_value<-output_value[updatable_outputs]

This was insufficiently robust, since valid return values from Dash callbacks can be objects in R which are members of more than one class.

As an example, if a callback returns list(htmlDiv(), ""), the class membership of its elements would be

> lapply(list(htmlDiv(), ""), class)
[[1]]
[1] "dash_component" "list" [[2]]
[1] "character"

The original definition of updatable_outputs would essentially attempt vapply(list(htmlDiv(), ""), class, character(1)) which produces the cryptic error

Error in vapply(list(htmlDiv(), ""), class, character(1)) : values must be length 1,
but FUN(X[[1]]) result is length 2

By rewriting the original line as

updatable_outputs <- vapply(output_value, function(x) !("no_update" %in% class(x)), logical(1))

class membership is inspected more flexibly, and a logical result is returned in the vapply step instead of a character vector of class names.

[rpkyle]

@alexcjohnson test for callbacks returning components added in eea0b46.

[alexcjohnson]

Perfect! 💃

[rpkyle]

This PR proposes a minor modification to the way Dash for R's _dash-update-component handler resolves multiple outputs in callbacks which return one or more Dash components. This bug was discovered accidentally while fixing another bug in the Dash for R docs.

Previously, updatable_outputs implicitly assumed output_value's elements were members of only one class, since the specified return type of vapply was character(1):

dashR/R/dash.R

Lines 477 to 478 in b3be88d

	updatable_outputs<-"no_update"!= vapply(output_value, class, character(1))
	output_value<-output_value[updatable_outputs]

This was insufficiently robust, since valid return values from Dash callbacks can be objects in R which are members of more than one class.

As an example, if a callback returns list(htmlDiv(), ""), the class membership of its elements would be

> lapply(list(htmlDiv(), ""), class)
[[1]]
[1] "dash_component" "list" [[2]]
[1] "character"

The original definition of updatable_outputs would essentially attempt vapply(list(htmlDiv(), ""), class, character(1)) which produces the cryptic error

Error in vapply(list(htmlDiv(), ""), class, character(1)) : values must be length 1,
but FUN(X[[1]]) result is length 2

By rewriting the original line as

updatable_outputs <- vapply(output_value, function(x) !("no_update" %in% class(x)), logical(1))

class membership is inspected more flexibly, and a logical result is returned in the vapply step instead of a character vector of class names.

[rpkyle]

@alexcjohnson test for callbacks returning components added in eea0b46.

[alexcjohnson]

Perfect! 💃

[rpkyle]

This PR proposes a minor modification to the way Dash for R's _dash-update-component handler resolves multiple outputs in callbacks which return one or more Dash components. This bug was discovered accidentally while fixing another bug in the Dash for R docs.

Previously, updatable_outputs implicitly assumed output_value's elements were members of only one class, since the specified return type of vapply was character(1):

dashR/R/dash.R

Lines 477 to 478 in b3be88d

	updatable_outputs<-"no_update"!= vapply(output_value, class, character(1))
	output_value<-output_value[updatable_outputs]

This was insufficiently robust, since valid return values from Dash callbacks can be objects in R which are members of more than one class.

As an example, if a callback returns list(htmlDiv(), ""), the class membership of its elements would be

> lapply(list(htmlDiv(), ""), class)
[[1]]
[1] "dash_component" "list" [[2]]
[1] "character"

The original definition of updatable_outputs would essentially attempt vapply(list(htmlDiv(), ""), class, character(1)) which produces the cryptic error

Error in vapply(list(htmlDiv(), ""), class, character(1)) : values must be length 1,
but FUN(X[[1]]) result is length 2

By rewriting the original line as

updatable_outputs <- vapply(output_value, function(x) !("no_update" %in% class(x)), logical(1))

class membership is inspected more flexibly, and a logical result is returned in the vapply step instead of a character vector of class names.

[rpkyle]

@alexcjohnson test for callbacks returning components added in eea0b46.

[alexcjohnson]

Perfect! 💃

[rpkyle]

This PR proposes a minor modification to the way Dash for R's _dash-update-component handler resolves multiple outputs in callbacks which return one or more Dash components. This bug was discovered accidentally while fixing another bug in the Dash for R docs.

Previously, updatable_outputs implicitly assumed output_value's elements were members of only one class, since the specified return type of vapply was character(1):

dashR/R/dash.R

Lines 477 to 478 in b3be88d

	updatable_outputs<-"no_update"!= vapply(output_value, class, character(1))
	output_value<-output_value[updatable_outputs]

This was insufficiently robust, since valid return values from Dash callbacks can be objects in R which are members of more than one class.

As an example, if a callback returns list(htmlDiv(), ""), the class membership of its elements would be

> lapply(list(htmlDiv(), ""), class)
[[1]]
[1] "dash_component" "list" [[2]]
[1] "character"

The original definition of updatable_outputs would essentially attempt vapply(list(htmlDiv(), ""), class, character(1)) which produces the cryptic error

Error in vapply(list(htmlDiv(), ""), class, character(1)) : values must be length 1,
but FUN(X[[1]]) result is length 2

By rewriting the original line as

updatable_outputs <- vapply(output_value, function(x) !("no_update" %in% class(x)), logical(1))

class membership is inspected more flexibly, and a logical result is returned in the vapply step instead of a character vector of class names.

[rpkyle]

@alexcjohnson test for callbacks returning components added in eea0b46.

[alexcjohnson]

Perfect! 💃

[rpkyle]

This PR proposes a minor modification to the way Dash for R's _dash-update-component handler resolves multiple outputs in callbacks which return one or more Dash components. This bug was discovered accidentally while fixing another bug in the Dash for R docs.

Previously, updatable_outputs implicitly assumed output_value's elements were members of only one class, since the specified return type of vapply was character(1):

dashR/R/dash.R

Lines 477 to 478 in b3be88d

	updatable_outputs<-"no_update"!= vapply(output_value, class, character(1))
	output_value<-output_value[updatable_outputs]

This was insufficiently robust, since valid return values from Dash callbacks can be objects in R which are members of more than one class.

As an example, if a callback returns list(htmlDiv(), ""), the class membership of its elements would be

> lapply(list(htmlDiv(), ""), class)
[[1]]
[1] "dash_component" "list" [[2]]
[1] "character"

The original definition of updatable_outputs would essentially attempt vapply(list(htmlDiv(), ""), class, character(1)) which produces the cryptic error

Error in vapply(list(htmlDiv(), ""), class, character(1)) : values must be length 1,
but FUN(X[[1]]) result is length 2

By rewriting the original line as

updatable_outputs <- vapply(output_value, function(x) !("no_update" %in% class(x)), logical(1))

class membership is inspected more flexibly, and a logical result is returned in the vapply step instead of a character vector of class names.

[rpkyle]

@alexcjohnson test for callbacks returning components added in eea0b46.

[alexcjohnson]

Perfect! 💃

[rpkyle]

This PR proposes a minor modification to the way Dash for R's _dash-update-component handler resolves multiple outputs in callbacks which return one or more Dash components. This bug was discovered accidentally while fixing another bug in the Dash for R docs.

Previously, updatable_outputs implicitly assumed output_value's elements were members of only one class, since the specified return type of vapply was character(1):

dashR/R/dash.R

Lines 477 to 478 in b3be88d

	updatable_outputs<-"no_update"!= vapply(output_value, class, character(1))
	output_value<-output_value[updatable_outputs]

This was insufficiently robust, since valid return values from Dash callbacks can be objects in R which are members of more than one class.

As an example, if a callback returns list(htmlDiv(), ""), the class membership of its elements would be

> lapply(list(htmlDiv(), ""), class)
[[1]]
[1] "dash_component" "list" [[2]]
[1] "character"

The original definition of updatable_outputs would essentially attempt vapply(list(htmlDiv(), ""), class, character(1)) which produces the cryptic error

Error in vapply(list(htmlDiv(), ""), class, character(1)) : values must be length 1,
but FUN(X[[1]]) result is length 2

By rewriting the original line as

updatable_outputs <- vapply(output_value, function(x) !("no_update" %in% class(x)), logical(1))

class membership is inspected more flexibly, and a logical result is returned in the vapply step instead of a character vector of class names.

[rpkyle]

@alexcjohnson test for callbacks returning components added in eea0b46.

[alexcjohnson]

Perfect! 💃