sort out valueAsOption vs valueAsId in select controls (Combo, GridPicker etc) about wingspan-forms

[newyankeecodeshop]

I've been thinking more about this, and I think that you're right that we can make everything "valueAsId" to make the programming model simpler. So the "value" prop would take one or more IDs, and the "onChange" would return one or more IDs. My only addition to this is to have "onChange" also return the valueAsObject in a second argument. So that one could have:

onChange: function (value, valueObject) {
    var newRecord = _.clone(this.state.record);
    newRecord['fooID'] = value;
    newRecord['fooName'] = valueObject.name;
    this.setState({ record: newRecord });
}

I like using a second argument for the "valueAsObject" because then people who just want to stick with IDs can totally ignore it.
What do you think?

[dustingetz]

Your proposal would lower the implementation complexity of valueAsObject and I think it's a good idea. The open question is if valueAsObject ought to be permitted at all as it limits how far you can abstract.

[newyankeecodeshop]

At this point, I'd say to not permit "valueAsObject" at all. The client (or even AutoControl) can dereference object values pretty easily. My thought was to make AutoControl do this, so records that use object-style properties would be able to continue to work unchanged. AutoControl already knows what the "valueField" and "displayField" is for a combo...

[dustingetz]

I agree with you and think permitting only valueAsId would result in simpler application code. Just note that "dereferencing an object value" in the most general way possible probably requires ajax, which can lead to a very request heavy app, which is why no consensus on this issue was reached. Though I would expect a lot of the requests can be mitigated through browser cache and hand optimization in hot spots. I also expect that this is a pretty involved refactor (for the TMF).