Opened 12 years ago
Closed 12 years ago
#7718 closed feature (fixed)
instantiating widget with option of type array
Reported by: | sgruenholz | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 1.9.0 |
Component: | ui.widget | Version: | 1.8.16 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
I get an unexpected behavior when initializing a widget with an option of type array.
Example In a simple color picker we use an array of hex values. These define the default color swatches for the color picker.
$.widget("some.simple_color_picker", { // default color swatches options: { colors: ['#000','#333','#666','#bbb','#ddd','#fff'] }, _create: function() { console.log("options.colors", this.options.colors); } });
Instantiation When instantiating a color picker instance, I can then define my own custom set of color swatches to use for each one.
$('#some_elem').simple_color_picker({ colors: ['#FF0000', '#00FF00', '#0000FF'] });
But instead of replacing the default colors array with the new one (the expected behavior), it combines them. Logging the value of this.options.colors on _init() reveals:
['#FF0000', '#00FF00', '#0000FF', '#bbb', '#ddd', '#fff']
When options gets extended, it's treating our arrays like hashes and replacing values by index:
// default { 0: '#000', 1: '#333', 2: '#666', 3: '#bbb', 4: '#ddd', 5: '#fff' } // instance { 0: '#FF0000', 1: '#00FF00', 2: '#0000FF' } // extending these objects produces: { 0: '#FF0000', 1: '#00FF00', 2: '#0000FF', 3: '#bbb', 4: '#ddd', 5: '#fff' }
Workaround I've got a workaround where I use "options.default_colors" in the class and then instantiate with "options.colors", checking if the latter exists and using it instead. Or alternately we could use something like a delimited string of values and then parse them out... But, bottom line is the widget class exists to handle this for us in a friendly way.
Request Please consider "fixing" options to handle values of type array in the expected manner when a widget gets instantiated. Maybe this needs to get pushed up to the core method .extends() where the deep nesting stuff is happening...
This works properly in master. Probably from b9153258b0f0edbff49496ed16d2aa93bec07d95.