To be clear, I
think your approach is fine, and I'm not saying you
shouldn't use it. But I currently don't plan to teach it
because I think it's a distraction. (Also if you validation is
that complex wouldn't you want it be in a function so you could
test it outside of Shiny?)
— Hadley Wickham
(@hadleywickham) June
23, 2020
Personal preference:
I usually separate things so that anything that fails in Shiny uses validate(need), so reactives, inputs, are tested with that so that custom CSS can be applied and, more importantly, helpful messages can be displayed not just "on error" but as a suggestive message of how to proceed through the app.
I don't
think so, in almost every web interface registering a password you get
instant feedbacks about the password you're setting. For example
on GitHub: pic.twitter.com/kmCxcmxHDX
—
Colin Fay 🤘 (@_ColinFay) June
23, 2020
If a function is vitally important, and its logic is not dependent on Shiny, I write as a function (like writing a package) that has zero dependency on shiny. In that case a regular if(FALSE)stop("message") is used, no validation(). An added benefit is now this function can be borrowed for use elsewhere without calling a dependency on Shiny.