* Close#3235: Don't change the return value of bootstrapPage() if bslib isn't relevant
Also, improved error message if theme is a character vector with 2 or more elements
* yarn build (GitHub Actions)
* bump version
* yarn build (GitHub Actions)
* Don't add an additional level to the returned tree structure
* More straightforward use of do.call()
Co-authored-by: cpsievert <cpsievert@users.noreply.github.com>
Co-authored-by: Winston Chang <winston@stdout.org>
* leverage bslib's color-contrast() in sliderInput()'s Sass and reduce number of git patches
* Use color-contrast() instead of color-yiq() in Bootstrap Datepicker
* disable stylesheet on next tick to avoid FOUC
* fix regex matching logic
* Avoid regex and remove stylesheet's ownerNode after disabling
* Use inline <style> as opposed to <link> tags when restyling for IE11 compatibility
* Be more careful to avoid possibility of removal modifying styleSheets
* Use inline <style> for IE; otherwise update the <link>
* Update srcjs/output_binding_html.js
Co-authored-by: Winston Chang <winston@stdout.org>
* Update browser.js to correctly detect IE11
* remove redundant if statements
Co-authored-by: Winston Chang <winston@stdout.org>
This brings it into line with all of the other input bindings.
The only exception is sliderInput, which has a more complicated
codepath that goes out of its way to force the slider, for its
own reasons; I didn't change the slider for fear of breaking
something, and it also doesn't exhibit the problem I'm here to
fix (next paragraph).
The goal is to ensure that if forgetLastInput is called on an
input, and then that input receives a message (updateXXXInput)
to update its value, BUT the new value is the SAME as its
existing value, that the input binding still acts like something
changed. This is because we need the id/value to go through
the InputSender code path, and alert the server if a previously
frozen input is now thawed.
1. freezeReactiveValue(input, "x") is called, inside a renderUI
or in an observer that then calls updateXXXInput
2. Some reactive output tries to access input$x, this takes a
reactive dependency but throws a (silent) error
3. When the flush cycle ends, it automatically thaws
What's *supposed* to happen next is the client receives the new
UI or updateXXXInput message, which causes input$x to change,
which causes the reactive output to invalidate and re-run, this
time without input$x being frozen.
This works, except when the renderUI or updateXXXInput just so
happens to set input$x to the same value it already is. In this
case, the client would detect the duplicate value and not send
it to the server. Therefore, the reactive output would not be
invalidated, and effectively be "stalled" until the next time it
is invalidated for some other reason.
With this change, freezeReactiveValue(input, "x") has a new side
effect, which is telling the client that the very next update to
input$x should not undergo duplicate checking.
* Sassify shiny.css (& make it themable); gut json2 dependency (was there for IE8 support)
* Always serve a compressed bundle; remove shiny.css
* Use getCurrentTheme() and make sure shinyDependencies is a function
* Make sure we have sass/rprojroot before running checkBuilt.sh
* Need repos set
* Compare against bleeding edge of sass
* Perform built check with testthat (copying the approach taken for pkgdown checks)
* Update tests/testthat/test-built-files.R
Co-authored-by: Winston Chang <winston@stdout.org>
Co-authored-by: Winston Chang <winston@stdout.org>
* Allow setting the state of RestoreContext
This setter only sets public fields, but it's still necessary because
the RestoreInputSet R6 class is not exported.
(I needed this functionality for shinytableau config dialogs to do a
bookmark-like restore, but not at all based on querystring)
* Use list instead of values to prevent accidental mutation
See discussion here:
https://github.com/rstudio/shiny/pull/3053#discussion_r488948453
* Rebuild JS for new version number
