A traditional Shiny input widget (sliderInput, selectizeInput, and so
on), hosted, not rebuilt in React. The server renders the
widget's own call through renderUI() (or host_input()), and this
shows that output: Shiny's own dynamic-UI binding loads the widget's
JS/CSS and binds it, so the widget behaves exactly as in a classic app.
shinyreact's maintainers recommend this over writing widget markup on
the client (posit-dev/shinyreact#286 and #294).
id is the output's full name, _ui suffix included
(<SliderInput id="bins_ui" /> for output$bins_ui), never the
widget's own input id: the output wrapper and the widget would then
share one DOM id. Inside a <Module>, the id is namespaced.
NavbarTabStrip.tsx, and LayoutSidebar when given an id, still call
Shiny's binding functions themselves (through useBoundScope), since
each mixes Shiny-bound markup with React-owned content in a way
renderUI() cannot express; see their own file comments.
A traditional Shiny input widget (sliderInput, selectizeInput, and so on), hosted, not rebuilt in React. The server renders the widget's own call through
renderUI()(orhost_input()), and this shows that output: Shiny's own dynamic-UI binding loads the widget's JS/CSS and binds it, so the widget behaves exactly as in a classic app. shinyreact's maintainers recommend this over writing widget markup on the client (posit-dev/shinyreact#286 and #294).idis the output's full name,_uisuffix included (<SliderInput id="bins_ui" />foroutput$bins_ui), never the widget's own input id: the output wrapper and the widget would then share one DOM id. Inside a<Module>, the id is namespaced.NavbarTabStrip.tsx, andLayoutSidebarwhen given anid, still call Shiny's binding functions themselves (throughuseBoundScope), since each mixes Shiny-bound markup with React-owned content in a wayrenderUI()cannot express; see their own file comments.