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.
#Shiny runjs jquery example code#
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)
