Widget Review

Widget options

Options

During _create(), all options must be applied unconditionally. This can be done by calling _setOption() for each this.options. If two options are not orthogonal, - the same code will be executed twice - the values may not be consistent (i.e., if option1 = x, option2 cannot = y -> which one takes precedence? We need to decide and then document)

During refresh(), we take data-* attributes from the DOM and we synch this.options. We must only set those options which have changed. Do we blindly call _setOption() for each, or do we execute internal, optimized code. Is there an opportunity to write a function that figures out which options need changing? A function to be placed in the superclass/into an extension? If we write such a function, and then loop over the options that need changing, we run into the same problem of non-orthogonal options.

During _set<Option>() we must set a second option or execute some common code if two options are not orthogonal. If the new option value would cause the non-orthogonal second option value to become invalid, we need to calculate a new value for the second option to bring it back to validity, or error out. We need to decide which we wish to do and then document that.

Option demultiplexing is generally OK, but we need to get rid of the exceptions.

Possible solution for non-orthogonal options: During _create(): We copy this.options, then we null-out all its values, and we call this._setOptions( copyOfOptions ). That will result in unconditionality and widgets that have non-orthogonal options can override the default implementation of _setOptions() which simply iterates over the options and calls _setOption() with each option. This subclassed version of _setOptions() can then chain up to the superclass with the reduced set of options (those that are orthogonal).

This is not good performance-wise, because we do a lot of going through a lot of functions in various widgets instead of dealing with the options in-widget. OTOH, it's much cleaner and more consistent.

Questions that need answering before we start

using on vs _on for elements which will be destroyed

how to do one with _on ?