interactive maps with tmap & mapview display earlier chunks on shinyapps #529
Comments
|
Thank you for posting the example app with session info. Unfortunately, I cannot reproduce the error you're seeing. In Chrome, Firefox and Safari on MacOS (Big Sur) the app returns the correct map regardless of the order in which the examples are run. What browser are you using? Have you tried reproducing the problem in other browsers on your machine? Does clicking "Start Over" to reset your progress in the tutorial resolve the issue? |
|
Good morning @gadenbuie, I'm a collaborator of @andysouth and gets the same. I'm on Ubuntu 20.04.2 and got the same in Firefox and Chrome. On closer inspection of https://andysouth.shinyapps.io/intro-to-spatial-r/ I wonder if it isn't because somewhere the The first maps are supposed to be displayed with I added Strangely though https://andysouth.shinyapps.io/intro-to-spatial-r/#section-f.-mapping-multiple-layers always renders the correct map without having to add |
|
Thanks @gadenbuie @anelda I see this problem on Windows Chrome, and Firefox. It seems to be intermittent. Yesterday it was working on Firefox. From the minimal example the shinyapps log messages associated with the problem are : 2021-05-25T08:14:24.672358+00:00 shinyapps[4177430]: Warning in selectChildren(jobs, timeout) : Clicking 'Start over' for the minimal example does allow the latter plots to run correctly, but only if the earlier plots are not run beforehand. |
|
To note @gadenbuie that I've also just seen the same behaviour in a RStudio cloud project running one of our tutorials. It similarly gave the message : tmap mode set to interactive viewing |
|
It turns out that the warning about non-existent children looks bad but is generally harmless, except that in this case it pointed me in the direction of the solution. That warning only shows up when using a forked evaluator and usually means that the exercise result returned cleanly and learnr didn't have to kill the process. The forked evaluator is the default evaluator on Linux, i.e. shinyapps.io. You can use a forked evaluator setup locally by adding the following to your setup chunk: Once I turn on the forked evaluator, I can reproduce the issue described here reliably, even locally on MacOS. It took me a bit to track down the root cause, but it ultimately comes down to the forked evaluator model: with a forked evaluator, each exercise submission is run in a fork of the current R process. The forked evaluator uses How does this cause problems for tmap? With Here's the final solution: for each interactive map, set the seed of the htmlwidget ids to a different number in an exercise setup chunk: The Please give this idea a try and let me know if it works for you! |
|
Many thanks @gadenbuie for the detective work - a tricky operating system dependent one - and comprehensive explanation. I'll try out the solution and report back. |
|
Thanks @gadenbuie this solution does work for us. Implemented here : https://andysouth.shinyapps.io/intro-to-spatial-r/#section-e.-first-maps-with-tmap (One side note that setting the forked_evaluator to generate the issue locally did not work for me locally on Windows, with that pressing Run on a chunk gave : Error in : 'mcparallel' is not an exported object from 'namespace:parallel') |
|
This issue would apply to anything that uses A few potential solutions come to mind:
More research is needed for option 1. Option 2 seems most straightforward, if it's possible to get the name of the currently executing chunk. |
|
Thanks @kcarnold for bumping this issue and for brainstorming some solutions!
I like this idea and I think it'd be reasonable for learnr to do this in general, e.g. the exercise evaluator could easily hash the exercise label (i.e. the chunk name) into an integer value before executing the exercise. Randomness is already a bit tricky in learnr and this would make outputs consistent between both runs and across environments. We might want to add an "escape hatch" (an exercise-level option) for authors who really really really want random values to be generated between exercise runs. I'm envisioning an |
|
Unfortunately, we can't fix this with seed setting/management alone and we'll need a change in htmlwidgets or in our forked evaluator to fix this. The crux of the issue looks more or less like this:
I submitted a PR upstream in htmlwidgets that would change this behavior so that htmlwidgets would only manage it's own ID seed when the user calls The other option would be for learnr to switch from forked processes to using callr, futures, or promises, but for that to be an effective solution for this particular problem, we'd need to completely evaluate the exercise start-to-finish in a background process, which would come with at least few drawbacks. |
System details
Output of
sessioninfo::session_info()():Example application or steps to reproduce the problem
On shinyapps learnr chunks display interactive maps from earlier chunks that have been run.
Minimal example app
Reproducible example code
Chunk1 makes an orange world map.
Chunk2 makes a blue world map.
Chunk3 makes an orange dot map.
Chunk4 makes a blue dot map.
If user Runs chunks 1-4 in that order, they all display map1.
If user runs chunk 3 then 4, both chunks display map3.
Happens on shinyapps but not locally.
Possibly related to issue fixed by RStudio in 2021-02 #484
Causing us problems with our tutorials here : afrimapr/afrilearnr#16
Thankyou!
The text was updated successfully, but these errors were encountered: