-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test if running under shinylive or server side? #45
Comments
Not sure if there is a built-in function call and/or session status to detect if the app running using Shiny or Shinylive. However, the following should work to detect whether the app is running using is_shinylive <- function() { R.Version()$arch == "wasm32"} Feel free check the detection with this Demo app. The only other way would be to check if the |
That works nicely. Until people start running entire servers using wasm32 architecture, of course. Sounds silly now, but who would have thought of nodejs when Netscape introduced Javascript! :) For completeness, here's a chunk of my
|
@barryrowlingson I understand the concern; but, given the intricacies of the WASM build and Shiny requirements + communication, I'm not sure we'll ever see shiny running on wasm outside of the shinylive case. |
Agree, this is fine. Would you add an |
I think this would be great to include in the shinylive R package. Would either of you like to contribute a PR? I think @coatless's proposed approach is great; for future compatibility we might want to account for BTW, I made a little app showcasing the function on shinylive.io. |
There's also the possibility of R.Version()$os == "emscripten" if we're worried about just checking for
Perhaps it makes sense as part of the shiny package itself? The shinylive R package is more useful for building and exporting an app, rather than at runtime in the app. For example, in the shinylive.io example above you can remove |
True; I was including Personally, I'd rather keep this check in shinylive. It's a bit closer to the place where the implementation might change. And shiny's a bigger and much slower to move package. Not that I'm super worried about this particular function, but it does seem possible that other runtime utility needs might pop up in the future. |
Ah, gotcha, that makes sense. One minor issue with loading the We should probably also check with @wch to see if there is some equivalent test for Python apps already in place that we should mimic. |
@georgestagg a quick grep through the https://github.com/posit-dev/py-shiny/blob/6ed505b18b3cfaab72d0a0a20762c4f0dc49b035/shiny/_shinyenv.py For parity with the Python version of shiny, I suppose this means So, I suppose the PR'd function should be: is_shinylive <- function() { R.Version()$os == "emscripten" } |
Not in the short term for webR. Perhaps in the future, when the Memory64 proposal has been standardised as part of the Wasm spec. |
If we keep the function in shinylive, it makes it easier to adjust if we end up needing to differentiate between flavors of shinylive (shinylive.io vs self-hosted shinylive apps). It also opens the door to having shinylive (the package) help with runtime calls inside shinylive apps if anything comes up in the future. Also we should consider using |
@gadenbuie if we opted to place the How about adding to the upstream
For the Sys.setenv("SHINYLIVE_APP" = "TRUE") Around line 144 in Then, there could be a check function defined inside of is_shinylive_app <- function() { Sys.getenv("SHINYLIVE_APP", "FALSE") == "TRUE" } On the need to detect Another possible option here would be to define a function that can access is_shinylive_io_app <- function() { session$clientData$url_hostname == "shinylive.io"} Feel free to tinker with the suggestions inside of the demo app. |
FWIW I think Garrick's argument is sound. Shiny is indeed a slow-moving package and if we start thinking about the possibility of other runtime utility functions, perhaps even functions that only make sense when running under Shinylive, it would probably be better to group and organise such functions within the The environment variable is also a strong idea. It sounds perfectly reasonable to me that we could see if we are running in the Shinylive environment by checking an environment variable, and they could be set by posit-dev/shinylive as part of the runtime initialisation so that they are set for all apps. Then, a user who wants to check for Shinylive without loading the So, my vote would be for some setup like:
Then, some or all of the following convenience functions are added to the
I should also mention that I just realised that, technically, posit-dev/shinylive could also directly define an |
This package is intended for use outside of shinylive -- it creates shinylive bundles. Runtime environment checks are a completely different set of functionality. Because of that, and because the proposed functions are so simple, I think it would be best not to put them in this package. It's also possible that this package will evolve in ways in the future that make it larger, which will increase the overhead even more for doing one of these checks. It'll never be possible to run non-shinylive shiny in emscripten, so if you have a shiny app and you are running on emscripten, you can be certain that you're in shinylive. I've added an is_emscripten <- function() Sys.info()[["sysname"]] == "Emscripten" (@georgestagg note that I used |
I think it could make sense to add a |
Regarding environment variables, another interesting option to consider is setting |
Following up on the environment variable discussion above, it's likely we don't need to set any environment variables from Shinylive after all, since R itself already sets So, some other base R options could be,
or similar. We briefly discussed setting a |
I'm proposing we do it for convenience with existing R tooling, rather than out of necessity or feature parity with Python. I'll move that suggestion to a new issue in https://github.com/posit-dev/shinylive/ |
I've got a shiny app which has some issues running under shiny live, which I think I've narrowed down to its use of
shinyscreenshot
. Commenting out thescreenshotButton
in theui
fixes it.But is there a way of testing if the app is running under shinylive so I can include the button if it is running on a server and therefore does work? Something like:
or maybe an
ifelse
structure.The text was updated successfully, but these errors were encountered: