Submit data with the form indicating which button was clicked

[philippfromme]

Using a HTML form a button <button name="type" value="cancel" /> attribute would show up as type=cancel when submitting the form.

Button form fields currently have a key property that isn't used. It should be submitted along with all other data.

const data = {
  name: 'John Doe'
};

const schema = {
  "components": [
    {
      "key": "name",
      "type": "textfield"
    }.
    {
      "action": "submit",
      "label": "Cancel",
      "key": "cancel",
      "type": "button"
    },
    {
      "action": "submit",
      "label": "Submit",
      "key": "submit",
      "type": "button"
    }
  ],
  "type": "default"
}

const form = await createForm({
  container,
  data,
  schema
});

// user clicks "Cancel" ➡️ { name: "John Doe", cancel: "submit" }

// user clicks "Submit" ➡️ { name: "John Doe", submit: "submit" }

If the user decides to use buttons with a key property they'd have to make sure not to reuse these in the form.

---

Follow-up issue to https://github.com/bpmn-io/form-js/issues/212

[Skaiir]

@philippfromme I'd like to argue against this issue.

Correct me if I'm wrong, but what we want to do here is to potentially in the future return the result of whatever button was clicked in the form. This is a many to one relationship where multiple buttons might feed into the same 'result', which we'll then want to use for some kind of future operations.

The way I see this, key already has a well defined behavior, it binds form state to a field, in a one to one manner, this is different as we're not dealing with state but rather an event of a button press, it would be confusing to use it for such a functionality. Furthermore that use case is currently only theoretical and hasn't popped up on the roadmap. I would close the ticket and instead if we want this kind of a functionality in the future, have it be a bespoke property separate from key.

@nikku for visibility

[nikku]

Considering complex forms it is a neat way to decide what the user chose. Just a trivial example (creating a roll play game with form-js):

However, requirements are slightly different: I may want to bind different buttons to the same property (key). Depending on which button I click the value of action (or whatever) is either go west, go east or rest. As a user I want to define these buttons and be able to distinguish them.

Not sure if the issue represents this. @philippfromme can you elaborate?

[Skaiir]

@nikku I don't disagree that this behavior might be wanted in the future, this is also how I understood the potential usage of key. My only concern here is that it diverges quite significantly to how key is used everywhere else. In my view this shift in behavior should be reflected by using a different properties panel entry altogether.

[nikku]

My proposal is to keep this issue open and rewrite it based on (https://github.com/bpmn-io/form-js/issues/223#issuecomment-1217701724). Whether we use key or not is an implementation detail, and you concerns are absolutely justified.

[philippfromme]

I agree, whether we use key for this behavior or not is a detail. I remember creating this issue at @nikku's request.

[Skaiir]

Resurrecting this one a little, as things have advanced. So this is kind of an interesting idea, you could have different buttons for a scenario where you'd have branching logic. For example "escalate" / "resolve" for an issues management system.

The way I see it now, would be to have a property that is defined at the root of the form. This would be a sort of global key for the form submission which would be rendered withing the buttons setting with a description along the lines of "this key is shared across buttons". As mentioned this is an implementation detail but I'd still name it something slightly different to key, simply to not confuse the details. Then we'd have a second field which defines a "result" value that gets published to the data.

This would work pretty much like modal boxes, .NET example: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/app-development/how-to-return-a-dialog-box-result?view=netframeworkdesktop-4.8

@christian-konrad Do you think there's a use case here? This seems like a low hanging fruit and could give additional control to forms. Of course a similar effect can be achieved with a select component, but it's not quite as satisfying.

@volodymyr-melnykc Looping you in, as this would go around our whole idea of getting rid of buttons. Maybe we shouldn't do that so fast but instead support rendering these buttons in tasklist.

Within the modelers, we could then make clever usage of linting rules to:

• Restrict the buttons to the bottom of the form
• Enforce the setting of result value when users want to implement custom buttons

I mean in any case it wouldn't hurt to implement this for the core library, but I don't want to get too ahead of myself here before we consider impacts on modelers.

[christian-konrad]

We want to do this via "custom submit outcomes" on the user task level, instead as on the form level - we can quickly chat about it @Skaiir

[christian-konrad]

Alternatively we allow to define it on the form root as you mentioned - which would allow to bind conditions to those outcomes, which is not possible on the root level

@volodymyr-melnykc and @Skaiir maybe you can research how competitors solve "submit outcomes"?

[volodymyr-melnykc]

I created a task to do the research (to not lose track of it): https://github.com/camunda/product-design/issues/958