insure `component` retains `list`
timelyportfolio opened this issue · comments
As pointed out in ramnathv/htmlwidgets#477 and glin/reactable#348, htmlwidgets::JS
will no longer work as expected in reactR::component
. I think @glin fix in glin/reactable@1d60ea6 might be the solution that we could make universal if applied in reactR
.
Hi @timelyportfolio, thanks for the fix here and apologies for the disruption. reactR's use of JS()
was definitely not something I anticipated when working on the PR that changed the recursive behavior of htmltools::shouldEval()
.
Would you be able to show me in a small example how reactR uses JS()
? It would help me to understand the scope of the problems this new behavior is causing.
@gadenbuie thanks so much for working through this. Happy to schedule a time to discuss if that works best. My best summary of how reactR
uses JS()
is that a reactR::component
is a thin wrapper of shiny.tag
. Any reactR
widget is nearly identical to an htmlwidget
except there might be component
instead of shiny.tag
.
I will likely preserve this change regardless of decision in htmlwidgets
, since I do not see any negative side effects of preserving list
. @glin what are your thoughts?
@gadenbuie @timelyportfolio Thanks for fixes both in htmlwidgets and reactR. I don't see any downsides to leaving the workaround in either, especially because there are likely still users on htmlwidgets 1.6.3 out there, and it's kind of a hard issue to spot. I will probably leave in the workaround for reactable a little longer as well.
thanks @glin and @gadenbuie I'll plan to leave the patch to add list
to set of classes for reactR::component
.