[JS] Only enable action buttons if the values of their associated inputs have changed
This proposal is implemented here: https://github.com/microsoft/AdaptiveCards/pull/7104
Problem Statement
Currently, action buttons are always enabled or always disabled (via the isEnabled property).
Let's take the below scenario as a generic example:

In the above card, the "Save" button is always enabled, making it look like there's always something to save, which isn't true. Unless the user actually enters a value in either of the two inputs, there is nothing to save.
This existing model provides for a less than optimal user experience. A much better model would make it possible for the card author to specify that the "Save" button is to be disabled unless a value has been entered in one or more of its associated inputs. Essentially, the experience should be the following.
Before the user enters any value:

After the user has modified at least one input:

Proposed solution
- When a card is displayed, the inputs are all initially considered "clean", as in their values are current
- As the end user changes the value of an input, that input becomes "dirty"
- If the user happens to change the value of an input back to the value it originally had, the input becomes "clean" again
- Action.Submit and Action.Execute actions are enabled or disabled depending on the "dirty state" of the inputs they are associated with:
- If at least one input is "dirty", then the action is enabled
- Otherwise, the action is disabled
- If the action's
isEnabledis set to false, the action is permanently disabled (as is currently the case) - A property on Action.Submit and Action.Execute allows the card author to opt into the new behavior. The old behavior remains the default.
Details
We could simply make all this happen by default, but it is likely that the current behavior will need to be preserved for some existing scenarios. So we should make this an opt-in option for card authors.
We should introduce a new disabledUnlessAssociatedInputsChange Boolean property on Action.Submit and Action.Execute (which are the only two input-dependent action types). When disabledUnlessAssociatedInputsChange is set to false (the default), the current behavior (the action is always enabled) applies; if set to true, then the action is disabled if its isEnabled property is set to false OR if none of its associated inputs have changed (i.e. their values are the same as when the card was initially disaplyed).
As the end user changes the values of inputs and clicks an action button associated with those inputs, the "dirty state" of those inputs should be reset (as in, their new values are now considered current) and thus the action button should again become disabled. It is likely though that host applications might want to reset the inputs' dirty state on their own term, and thus we should add a global setting controlling whether or not the SDK automatically performs that reset.
Alternatives or Workarounds
There are no alternatives or workaround. Some scenarios have opted for pushing inputs and associated "Save" button into ShowCard just so that there wouldn't be a misleading, always enabled "Save" button on the main card.
I like this approach and only have one piece of input to consider (I didn't look at how difficult it would be to implement):
* Action.Submit and Action.Execute actions are enabled or disabled depending on the "dirty state" of the inputs they are associated with:
- * If at least one input is "dirty", then the action is enabled
+ * If at least one input is "dirty", and all required inputs are "dirty", then the action is enabled
* Otherwise, the action is disabled
@paulcam206 I considered doing that (in the JS SDK it's not difficult). The reason I didn't go for it is that an input might have an initial, valid value and thus satisfy its "required" criteria while not being dirty. What do you think?
Makes sense to me 👍
I'll take a look at the PR...
I'd like to use this functionality as I'm creating checkboxes for accepting Terms of Service and Privacy Policy, and rather than having the user click and an error message appear, I'd like to have the action disabled until both are checked. I see this was put into a prioritization queue about 20 months ago, any chance of a near-term implementation?