Unexpected val() event behavior

[ghost]

@bazineta commented on May 2, 2018, 10:50 PM UTC:

The change introduced in snapappointments/bootstrap-select#1303, such that calling val() emits a change event, is inconsistent with common practice, and, at least in our case, induced a lot of breakage, as it tends to introduce events before handlers are ready for them.

I'm a bit puzzled as to the rationale for the change; val() doesn't typically work this way. As reference, from the canonical val() documentation, http://api.jquery.com/val/:

Setting values using this method (or using the native value property) does not cause the dispatch of the change event. For this reason, the relevant event handlers will not be executed. If you want to execute them, you should call .trigger( "change" ) after setting the value.

I think if something as basic as event behavior is going to be different from how it's worked in the past and different from common practice, there should be much more of a warning present in the change log.

However, frankly, it's not without good reason that that's not normally the way val() works, so again, I'm puzzled by what seems to be an odd choice here.

This issue was moved by caseyjhol from snapappointments/bootstrap-select-temp#52.

[caseyjhol]

I agree - this behavior is inconsistent, and while it does make sense on the surface that val() should trigger a change event, it's trivial to simply trigger the change event manually. I'm considering deprecating val() for the next major release, as I'm failing to see the value it provides (especially if it doesn't trigger a change event), and we often run into other issues with it. Perhaps it should simply trigger changed.bs.select, and not the native change event.

[bazineta]

In our case, we've chosen to modify the 1.13 version to the 1.12 behavior, i.e.,

 val: function (value) {
      if (typeof value !== 'undefined') {
        this.$element.val(value);
        this.render();
        return this.$element;
      } else {
        return this.$element.val();
      }
    },

In that with this implementation, we can choose to follow a 'val' method with a chained call to change() if we so choose, but it's our choice, so we've got the flexibility to either silently set the value, or set it and trigger. With 1.13, there is no choice.

[caseyjhol]

Released in v1.13.7!