Use Case: There are numerous valid use cases where a confirmation message pop-up is useful even when not submitting a form. Case in point, we are currently able to do this using the ButtonWidget component(s) even when not configured to submit.
I look forward to hearing from anyone else who might agree with this, and/or if anyone has any further comments or questions.
Thanks!
Discussion posts and replies are publicly visible
Thanks for bringing it up. I see one use case here - inline grid row deletions. What are some of your other use cases where it's important to provide the user a confirmation option?
Dynamic links can do a lot - from setting or clearing local / rule input variable values, to directly writing, altering or deleting data in the database via inline smart service functions like a!writeToDataStoreEntity. I know I've personally run into more small or nich use cases than this in my development experience which I have long since forgotten the details of - and at many times I've had to choose between either being able to use rich text / link components, and being forced to use a (non-submitting) Button Widget just so I can have the safety net of a confirmation popup message. To me it's artificially restrictive to force us to make these compromises.
I realize that the evolutionary paths of the different components have been separate and/or disconnected (i.e. no links had this functionality at all until the SubmitLink was introduced), but now as the SAIL feature set has become more rich and components have been enhanced with greater flexibility, this particular item has started standing out more and more to me as a functionality gap.
I understand where you're coming from. I'm looking for the reasons why you felt it was important to have the safety net of the confirmation message. Only when the user is about to delete data or otherwise do something they can't reverse?
That's a primary use case, especially if we boil it down to the "do something they can't reverse" part (or perhaps, 'commit to a particular action' or similar), though there are probably other use cases where it would provide an extra benefit to require the user to confirm before the saveInto of a link executes.
From a pure usability standpoint it's just good to make error difficult and/or recovery easy wherever possible. Even in a case where a change is reversible, but it's a lengthy process to do so or requires an undue interruption (like needing to start a separate action or a related action on a completely different type of record), it would be good to have a confirmation message to mitigate the action from occurring in error.