This adds a check that triggers an error if Select2 was not able
to detect a copy of jQuery on the page. This should help users when
they are setting up Select2.
**Breaking change:** The full build no longer includes jQuery.
Previously, the full build included all requirements for Select2,
including jQuery, which meant that anyone looking for the optional
requirements had to possibly include multiple versions of jQuery
on their page. This means that anyone requiring Select2 to also
bundle jQuery will now need to include jQuery on their pages
alongside Select2. A copy of jQuery is included in the repository.
**Breaking change:** The AMD build of Select2 will now correctly
wrap the code in a `define` block. It will still create the named
blocks inside of the code, which should be valid in most AMD build
systems, so now Select2 is compatible with cases where the file
does not have the same name as the Select2 module name.
**Breaking change:** Select2 will re-use the AMD methods if they
are available on the page, but it will not longer leak the included
AMD loader to the global scope. The AMD methods will still be
available on the `jQuery.fn.select2.amd` namespace.
The `mock.js` test file has been renamed to `helpers.js` and will
handle the escalation of the `require` and `define` variables to
the global scope. It should be included in all test files, or the
tests will fail.
This closes https://github.com/select2/select2/issues/2946.
This adds a test that makes sure that the inline data attribute
overrides the options that are passed in during initialization.
This also adds a test for the `createTag` option, which is used
when tagging.
While deep nesting will not work on a standard `<select>`, we can
emulate it through data objects still, and just handle the display
of the data in the results.
This also means that the horrific deep-nested CSS is back to handle
the padding. I hope that will get fixed over time.
This also fixes one of the performance issues with adding array
data, as options are added at the very end instead of one by one.
There was a plan to universally use an array as the return from
query methods, but now that we've realized pagination and extra
things are impossible without it, we're going back to the return
object. Anyone looking to migrate their data should be returning
an object with the key `results` containing what they previously
returned.
This should fix https://github.com/select2/select2/issues/2898
Now that the data objects have the `element` property, we can test
to make sure it's a DOM element and then use it for selecting the
option. This allows us to select multiple options with the same id,
as well as handle cases where that is already happening.
You cannot use `$e.val()` to select two options with the same id,
as jQuery will reject it, but you can set the second option to
`.selected = true`, which is supported.
This improves the speeds of creating the `<option>` tags for array
data. By creating the HTML ahead of time and putting it into an
`<option>` element before passing it to jQuery, it cuts down on the
time it takes for jQuery to process the HTML string and convert it
into DOM elements. This proved to be incredibly slow.
This also changes the `item` function to return early when the
data exists. The `$e.data` call has also been switched to a
`$.data` call, which doesn't need to check the DOM to see if the
data attributes already exist. This cuts down on a bit of wasted
time, as the `data` key should never be present in the DOM, and it
should be ignored if it is.
This converts individual objects passed in through the `array`
parameter to `<option>` tags when Select2 is initialized. This
removes a lot of duplicate code from the `ArrayAdapter`, and keeps
everything closer to the native `<select>` element.
This introduces a breaking change from previous versions of Select2,
where the initial value for array data was blank, even if a blank
option was not present in the original array of objects. Now the
first object passed in will be selected by default, following the
behavior of a standard `<select>` element.
This breaking change does not affect `<select multiple="multiple">`
elements, which by default have no selection.
When using array data, and an option is selected, the data that is
attached to the DOM element will be run through `item` and should
have any private, automatically generated attributes added and
merged with it.
We should only be checking the option values that matter, such as
`id` and `text`, instead of checking all of the option values. This
will prevent unexpected breaking when new properties are added to
the options.
Existing properties should be covered by tests to avoid regressions.
We have to enforce ids being strings as the values of options within
a select will always be an id. This fixes an issue that we had with
array selections not being highlighted in the results.
