toddjordan / ember-cli-dynamic-forms

An Ember addon for creating dynamic forms
http://toddjordan.github.io/ember-cli-dynamic-forms/
MIT License
35 stars 16 forks source link

Should be able to manipulate a field based on the value of one or more other fields within a form #3

Open toddjordan opened 8 years ago

toddjordan commented 8 years ago

Often, fields have dependencies on each other, so that when one field is updated, a function gets run that can manipulate the other. Dynamic forms should allow implementers to provide a function that handles these interactions.

Conventions

interactions should live in forms/interactions/* and implement a function that has access to both the field(s) that were changed and the value of the field that that originated the change.

Examples

sloria commented 8 years ago

What do you think of using the formatter API for this? A formatter could optionally take the current form data, so that you could format a field based on other fields.

Something along the lines of:


// format-total.js
export default Ember.Object.extend({
  format(formData) {
    const transaction1 = formData.transaction1;
    const transaction2 = formData.transaction2;
    const originalValue = this.getValue();
    this.setValue(_.sum([transaction1, transaction2]));
  }
});

// form.js
// ...

  "options": {
    "focus":false,
    "fields": {
      "total": {
        "label": "Name",
        "events": {
          "change": "format-total"
        }
      },
    }
  }
toddjordan commented 8 years ago

Hey @sloria Sorry I missed this comment. Answer is you are right... Formatters can do this today I think. Under the covers formatters are leveraging the change event on an input. From the change event you can leverage the field and maybe the whole form object. It should also be able access the alpaca object. I leaning towards keeping the idea of formatters for formatting specific fields and and adding the concept of interactions for cross field dependencies. json-schema has a mechanism for claiming 2 fields as dependent on one another so I'd like to leverage that, so in the example you wouldn't have to refer to transaction1 and transaction1, making the interaction more generic.

Building a solution into the change event (and maybe also on keystroke and click) is a possible way to go. I need to give it some thought and research though. Thanks for the input!