It’s a fairly common problem, across all of web design, not just R/Shiny. If you dig around online you’ll notice that many people have brought this up on Stack Overflow, Github, and Google Groups. After the reset button was clicked, the uploaded image was still visible in the UI. It reset all the other elements of my app ( selectInputs, textInputss etc), but it didn’t reset the fileInput. I started implementing this by using the awesome reset function from shinyjs. This then allows the user to upload a new photo and repeat the process. The issue I ran into, is once you’ve finished marking your photo, if you want to then start a new photo, you need some way of resetting the fileInput, and removing the current photo.
#Shinyjs runjs stack overflow download#
Once you’ve finished, you can download the positions as a csv file. In short, nebula allows you to upload a photo of an otolith (fish ear bone), and mark the positions of the growth rings (like in a tree trunk). Metaprogramming is just fun), that's your prerogative.While working on my (currently WIP) package nebula, I ran into an issue with resetting the fileInput component in Shiny. Implementation above these other considerations (and let's face it,
That said, obviously, it's your project, and nobody is going to fault youįor making whatever tradeoffs you feel like.
#Shinyjs runjs stack overflow code#
So I think there are other good reasonsįor adding a thin layer of code for each function. That do.call(shinyjs::show, args) doesn't work (certainly that's an edgeĬase, but surprising nonetheless). It also means thatĪrgument name misspellings are not caught at the point they're committed.Īnd finally, the particular implementation you've used for jsFunc means Show usage hints and support argument autocompletion. Signature for all of these functions are function(.), when the JSįunctions on the other side are expecting specific arguments this is a bigĭisadvantage in usability, especially when using RStudio or other IDEs that That elegance is accrued to you, the implementer, not the users. The way these shinyjs functions are written right now, all the benefit of session$ns is supported on both, it just doesn't do anything in a The function I wrote was intended to work for both modules and regularĪpps. If you're interested inĪ quick dirty fix, most shinyjs functions should work if you change And I'll let you know if I find something wrong with proxy session,īut it's likely a problem on my thanks for bringing this to my attention. The code to address the issues you mentioned. Your points do make a lot of sense, I should refactor Programming as a cool exercise, but I haven't reevaluated the Package started off as a tiny fun pet project and I enjoyed the meta So just take the above as my two after reading your opinion, I think you're 100% right. If you value conciseness of implementation above these other considerations (and let's face it, metaprogramming is just fun), that's your prerogative. That said, obviously, it's your project, and nobody is going to fault you for making whatever tradeoffs you feel like. So I think there are other good reasons for adding a thin layer of code for each function. And finally, the particular implementation you've used for jsFunc means that do.call(shinyjs::show, args) doesn't work (certainly that's an edge case, but surprising nonetheless). It also means that argument name misspellings are not caught at the point they're committed. The signature for all of these functions are function(.), when the JS functions on the other side are expecting specific arguments this is a big disadvantage in usability, especially when using RStudio or other IDEs that show usage hints and support argument autocompletion.
The way these shinyjs functions are written right now, all the benefit of that elegance is accrued to you, the implementer, not the users. session$ns is supported on both, it just doesn't do anything in a regular app. The function I wrote was intended to work for both modules and regular apps.
0 kommentar(er)
