microsoft / microsoft/AdaptiveCards

[JS] Only enable action buttons if the values of their associated inputs have changed

Open
#7,103 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Request
Dominant language
C#
Stars
2k
Forks
595
Avg merge
1d 19h
Merged PRs (30d)
1

Description

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:
image

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:
image

After the user has modified at least one input:
image

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 isEnabled is 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the linked pull request, #7104, alongside this issue's proposed behavior for Action.Submit and Action.Execute. Check how the JavaScript implementation tracks associated input values and handles the optional reset setting. Done means the opt-in property, dirty-state transitions, permanent isEnabled behavior, and post-action reset semantics are covered.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.