Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
class Multiselect extends HTMLDivElement {
|
|
|
|
|
constructor() {
|
|
|
|
|
super();
|
|
|
|
|
this.initialized = false;
|
|
|
|
|
this.toSearch = '';
|
2023-03-18 06:17:28 +00:00
|
|
|
|
this.highlighted = 0;
|
2023-04-09 22:05:29 +00:00
|
|
|
|
this.onFocusOutHandler = this.onFocusOut.bind(this);
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
connectedCallback() {
|
2023-04-09 22:05:29 +00:00
|
|
|
|
if (!this.isConnected) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
if (!this.initialized) {
|
|
|
|
|
for (const child of this.children) {
|
|
|
|
|
switch (child.nodeName) {
|
|
|
|
|
case 'SELECT':
|
|
|
|
|
this.select = child;
|
|
|
|
|
break;
|
|
|
|
|
case 'LABEL':
|
|
|
|
|
this.label = child;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (this.label && this.select) {
|
|
|
|
|
this.init();
|
|
|
|
|
}
|
|
|
|
|
}
|
2023-04-09 22:05:29 +00:00
|
|
|
|
window.addEventListener('focusin', this.onFocusOutHandler);
|
|
|
|
|
document.addEventListener('click', this.onFocusOutHandler);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
disconnectedCallback() {
|
|
|
|
|
document.removeEventListener('click', this.onFocusOutHandler);
|
|
|
|
|
window.removeEventListener('focusin', this.onFocusOutHandler);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
onFocusOut(e) {
|
|
|
|
|
if (this.contains(e.target)) return;
|
|
|
|
|
if (!e.target.isConnected) return;
|
|
|
|
|
this.close();
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
init() {
|
|
|
|
|
this.initialized = true;
|
|
|
|
|
|
|
|
|
|
this.select.style.display = 'none';
|
|
|
|
|
for (const option of this.select.options) {
|
|
|
|
|
option.dataset.numerusSearch = Multiselect.normalize(option.textContent);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
this.tags = document.createElement('div');
|
|
|
|
|
this.append(this.tags);
|
|
|
|
|
this.tags.classList.add('tags');
|
|
|
|
|
this.tags.addEventListener('click', () => this.toggle());
|
|
|
|
|
|
|
|
|
|
this.search = document.createElement('input');
|
|
|
|
|
this.tags.append(this.search);
|
|
|
|
|
this.search.id = this.select.id;
|
|
|
|
|
this.select.removeAttribute('id');
|
2023-03-18 06:17:28 +00:00
|
|
|
|
this.select.setAttribute('aria-hidden', 'true');
|
|
|
|
|
this.search.setAttribute('spellcheck', 'false');
|
|
|
|
|
this.search.setAttribute('autocomplete', 'false');
|
|
|
|
|
this.search.setAttribute('role', 'combobox');
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
this.search.addEventListener('input', (e) => {
|
|
|
|
|
this.open();
|
|
|
|
|
this.filter(e.target.value);
|
|
|
|
|
});
|
|
|
|
|
this.search.addEventListener('keydown', (e) => {
|
|
|
|
|
switch (e.code) {
|
|
|
|
|
case "Enter":
|
|
|
|
|
e.preventDefault();
|
2023-03-18 06:17:28 +00:00
|
|
|
|
this.selectHighlighted();
|
|
|
|
|
break;
|
|
|
|
|
case "ArrowDown":
|
|
|
|
|
if (e.altKey) {
|
|
|
|
|
this.open();
|
|
|
|
|
} else {
|
|
|
|
|
e.preventDefault();
|
|
|
|
|
this.highlightNext();
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case "ArrowUp":
|
|
|
|
|
if (e.altKey) {
|
|
|
|
|
this.close();
|
|
|
|
|
} else {
|
|
|
|
|
e.preventDefault();
|
|
|
|
|
this.highlightPrev();
|
|
|
|
|
}
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
break;
|
|
|
|
|
case "Backspace":
|
|
|
|
|
if (e.target.value === '') {
|
|
|
|
|
this.deselectLast();
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case "Escape":
|
|
|
|
|
this.close();
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
// Must come after the search input
|
|
|
|
|
this.tags.append(this.label);
|
|
|
|
|
|
|
|
|
|
this.options = document.createElement('ul');
|
|
|
|
|
this.append(this.options);
|
2023-03-18 06:17:28 +00:00
|
|
|
|
this.options.id = this.search.id + '-options-' + Array.from(crypto.getRandomValues(new Uint8Array(4))).map(n => n.toString(16)).join('');
|
|
|
|
|
this.search.setAttribute('aria-controls', this.options.id);
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
this.options.classList.add('options');
|
2023-03-18 06:17:28 +00:00
|
|
|
|
this.options.setAttribute('role', 'listbox');
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
this.close();
|
|
|
|
|
|
|
|
|
|
this.rebuild();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rebuildOptions() {
|
|
|
|
|
this.options.innerHTML = '';
|
2023-03-18 06:17:28 +00:00
|
|
|
|
let highlight = true;
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
for (const option of this.select.options) {
|
|
|
|
|
if (!this.isOptionSelectable(option)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
const li = document.createElement('li');
|
|
|
|
|
this.options.append(li);
|
2023-03-18 06:17:28 +00:00
|
|
|
|
li.id = this.options.id + '-' + option.index;
|
|
|
|
|
li.dataset.index = option.index;
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
li.textContent = option.textContent;
|
|
|
|
|
li.addEventListener('click', () => this.selectOption(option, true));
|
2023-03-18 06:17:28 +00:00
|
|
|
|
if (highlight && (option.index >= this.highlighted)) {
|
|
|
|
|
highlight = false;
|
|
|
|
|
this.highlight(null, li);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (highlight) {
|
|
|
|
|
this.highlight(null, this.options.querySelector('li:last-child'));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
highlightNext() {
|
|
|
|
|
const current = this.currentHighlighted();
|
|
|
|
|
if (!current) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
this.highlight(current, current.nextElementSibling);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
highlightPrev() {
|
|
|
|
|
const current = this.currentHighlighted();
|
|
|
|
|
if (!current) {
|
|
|
|
|
return;
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
}
|
2023-03-18 06:17:28 +00:00
|
|
|
|
this.highlight(current, current.previousElementSibling);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
highlight(current, upcoming) {
|
|
|
|
|
if (!upcoming) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (current) {
|
|
|
|
|
current.classList.remove('highlight');
|
|
|
|
|
}
|
|
|
|
|
upcoming.classList.remove('highlight');
|
|
|
|
|
this.search.setAttribute('aria-activedescendant', upcoming.id);
|
|
|
|
|
this.highlighted = upcoming.dataset.index;
|
|
|
|
|
upcoming.classList.add('highlight');
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
currentHighlighted() {
|
|
|
|
|
return document.getElementById(this.search.getAttribute('aria-activedescendant'));
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
isOptionSelectable(option) {
|
2023-03-18 06:17:28 +00:00
|
|
|
|
if (!option) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
if (option.selected) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return this.toSearch === '' || option.dataset.numerusSearch.includes(this.toSearch);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
selectOption(option, selected) {
|
2023-03-18 06:17:28 +00:00
|
|
|
|
if (!option) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
option.selected = selected;
|
|
|
|
|
this.toSearch = this.search.value = '';
|
|
|
|
|
this.rebuild();
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-18 06:17:28 +00:00
|
|
|
|
selectHighlighted() {
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
if (!this.isOpen()) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2023-03-18 06:17:28 +00:00
|
|
|
|
const option = this.select.options[this.highlighted];
|
|
|
|
|
if (this.isOptionSelectable(option)) {
|
|
|
|
|
this.selectOption(option, true);
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
deselectLast() {
|
|
|
|
|
const options = this.select.options;
|
|
|
|
|
for (let i = options.length - 1; i >= 0; i--) {
|
|
|
|
|
const option = options[i];
|
|
|
|
|
if (option.selected) {
|
|
|
|
|
this.selectOption(option, false);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rebuild() {
|
|
|
|
|
this.rebuildTags();
|
|
|
|
|
this.rebuildOptions();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rebuildTags() {
|
|
|
|
|
this.tags.querySelectorAll('.tag').forEach((tag) => tag.remove());
|
|
|
|
|
let empty = true;
|
|
|
|
|
for (const option of this.select.options) {
|
|
|
|
|
if (!option.selected) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
empty = false;
|
|
|
|
|
const tag = document.createElement('div');
|
|
|
|
|
this.tags.insertBefore(tag, this.search);
|
|
|
|
|
tag.classList.add('tag');
|
|
|
|
|
tag.dataset.numerusSearch = option.dataset.numerusSearch;
|
|
|
|
|
|
|
|
|
|
const span = document.createElement('span');
|
|
|
|
|
tag.append(span);
|
|
|
|
|
span.textContent = option.textContent;
|
|
|
|
|
|
|
|
|
|
const button = document.createElement('button');
|
|
|
|
|
tag.append(button);
|
|
|
|
|
button.type = 'button';
|
|
|
|
|
button.textContent = '×';
|
|
|
|
|
button.addEventListener('click', (e) => {
|
|
|
|
|
e.stopPropagation();
|
|
|
|
|
this.selectOption(option, false)
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
if (empty) {
|
|
|
|
|
this.search.setAttribute('placeholder', this.label.textContent);
|
|
|
|
|
} else {
|
|
|
|
|
this.search.removeAttribute('placeholder');
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
close() {
|
|
|
|
|
this.options.style.display = 'none';
|
2023-03-18 06:17:28 +00:00
|
|
|
|
this.search.setAttribute('aria-expanded', 'false');
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
open() {
|
|
|
|
|
this.options.removeAttribute('style');
|
2023-03-18 06:17:28 +00:00
|
|
|
|
this.search.setAttribute('aria-expanded', 'true');
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
toggle() {
|
|
|
|
|
if (this.isOpen()) {
|
|
|
|
|
this.close();
|
|
|
|
|
} else {
|
|
|
|
|
this.open();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
isOpen() {
|
|
|
|
|
return !this.options.hasAttribute('style');
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
filter(search) {
|
|
|
|
|
this.toSearch = Multiselect.normalize(search);
|
|
|
|
|
this.rebuildOptions()
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static normalize(s) {
|
|
|
|
|
return s.normalize('NFD').replace(/\p{Diacritic}/gu, '').toLowerCase().trim();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-19 22:11:40 +00:00
|
|
|
|
class Tags extends HTMLDivElement {
|
|
|
|
|
constructor() {
|
|
|
|
|
super();
|
|
|
|
|
this.initialized = false;
|
|
|
|
|
this.tags = [];
|
2023-04-09 22:05:29 +00:00
|
|
|
|
this.onFocusOutHandler = this.onFocusOut.bind(this);
|
2023-03-19 22:11:40 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
connectedCallback() {
|
2023-04-09 22:05:29 +00:00
|
|
|
|
if (!this.isConnected) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2023-03-19 22:11:40 +00:00
|
|
|
|
if (!this.initialized) {
|
|
|
|
|
for (const child of this.children) {
|
|
|
|
|
switch (child.nodeName) {
|
|
|
|
|
case 'INPUT':
|
|
|
|
|
this.input = child;
|
|
|
|
|
break;
|
|
|
|
|
case 'LABEL':
|
|
|
|
|
this.label = child;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (this.label && this.input) {
|
|
|
|
|
this.init();
|
|
|
|
|
}
|
|
|
|
|
}
|
2023-04-09 22:05:29 +00:00
|
|
|
|
window.addEventListener('focusin', this.onFocusOutHandler);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
disconnectedCallback() {
|
|
|
|
|
window.removeEventListener('focusin', this.onFocusOutHandler);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
onFocusOut(e) {
|
|
|
|
|
if (this.contains(e.target)) return;
|
|
|
|
|
if (e.target.value && e.target.value.trim() !== '') {
|
|
|
|
|
this.createTag();
|
|
|
|
|
}
|
2023-03-19 22:11:40 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
init() {
|
|
|
|
|
this.initialized = true;
|
|
|
|
|
|
|
|
|
|
this.tagList = document.createElement('div');
|
|
|
|
|
this.append(this.tagList);
|
|
|
|
|
this.tagList.classList.add('tags');
|
|
|
|
|
|
|
|
|
|
this.input.type = 'hidden';
|
|
|
|
|
const tagsText = this.input.value.split(',');
|
|
|
|
|
for (const tagText of tagsText) {
|
|
|
|
|
const tagNormalized = Tags.normalize(tagText);
|
|
|
|
|
if (tagNormalized !== '' && this.tags.indexOf(tagNormalized) === -1) {
|
|
|
|
|
this.tags.push(tagNormalized);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
this.search = document.createElement('input');
|
|
|
|
|
this.tagList.append(this.search);
|
|
|
|
|
this.search.id = this.input.id;
|
|
|
|
|
this.input.removeAttribute('id');
|
|
|
|
|
this.input.setAttribute('aria-hidden', 'true');
|
|
|
|
|
this.search.setAttribute('spellcheck', 'false');
|
|
|
|
|
this.search.setAttribute('autocomplete', 'false');
|
|
|
|
|
this.search.addEventListener('keydown', (e) => {
|
|
|
|
|
switch (e.code) {
|
|
|
|
|
case "Space":
|
|
|
|
|
e.preventDefault();
|
|
|
|
|
// fallthrough
|
|
|
|
|
case "Enter":
|
|
|
|
|
if (e.target.value.trim() !== '') {
|
|
|
|
|
e.preventDefault();
|
|
|
|
|
this.createTag();
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case "Backspace":
|
|
|
|
|
if (e.target.value === '') {
|
|
|
|
|
this.removeLastTag();
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
// Must come after the search input
|
|
|
|
|
this.tagList.append(this.label);
|
|
|
|
|
|
|
|
|
|
this.rebuild();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rebuild() {
|
Trigger filter form on change and search, as well as submit as before
Changed the invoice number field’s type to search to add the delete icon
on Chromium. Firefox does not add that icon, but i do not care; it is
still better that type="text".
Had to emit the change event to the numerus-tag field, otherwise the
form would not detect the change.
I also can not use keyup as a trigger because the changed modifier can
not be used in the <form>, as nothing ever changes, i do not know how to
trigger the form from children (i.e., data-hx-trigger on the <input>
does nothing), and i can not trigger for just any keyup, or i would
make the request even if they only moved the cursor with the arrow keys,
which is very confusing as Firefox resets the position (this may be due
the fact that i reload the whole <main>, but still).
2023-04-03 10:45:15 +00:00
|
|
|
|
const newValue = this.tags.join(',');
|
|
|
|
|
if (newValue !== this.input.value) {
|
|
|
|
|
this.input.value = newValue;
|
|
|
|
|
this.input.dispatchEvent(new Event('change', {bubbles: true}));
|
|
|
|
|
}
|
2023-03-19 22:11:40 +00:00
|
|
|
|
this.tagList.querySelectorAll('.tag').forEach((tag) => tag.remove());
|
|
|
|
|
if (this.tags.length === 0) {
|
|
|
|
|
this.search.setAttribute('placeholder', this.label.textContent);
|
|
|
|
|
} else {
|
|
|
|
|
this.search.removeAttribute('placeholder');
|
|
|
|
|
for (const tagText of this.tags) {
|
|
|
|
|
const tag = document.createElement('div');
|
|
|
|
|
this.tagList.insertBefore(tag, this.search);
|
|
|
|
|
tag.classList.add('tag');
|
|
|
|
|
|
|
|
|
|
const span = document.createElement('span');
|
|
|
|
|
tag.append(span);
|
|
|
|
|
span.textContent = tagText;
|
|
|
|
|
|
|
|
|
|
const button = document.createElement('button');
|
|
|
|
|
tag.append(button);
|
|
|
|
|
button.type = 'button';
|
|
|
|
|
button.textContent = '×';
|
|
|
|
|
button.addEventListener('click', (e) => {
|
|
|
|
|
e.stopPropagation();
|
|
|
|
|
this.removeTag(tagText)
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
createTag() {
|
|
|
|
|
const tagText = Tags.normalize(this.search.value);
|
|
|
|
|
this.search.value = '';
|
|
|
|
|
if (this.tags.indexOf(tagText) === -1) {
|
|
|
|
|
this.tags.push(tagText);
|
|
|
|
|
this.rebuild();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static normalize(s) {
|
|
|
|
|
return s.normalize('NFD').replace(/\p{Diacritic}/gu, '').toLowerCase().trim();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
removeLastTag() {
|
|
|
|
|
this.tags.pop();
|
|
|
|
|
this.rebuild();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
removeTag(tagText) {
|
|
|
|
|
this.tags.splice(this.tags.indexOf(tagText), 1);
|
|
|
|
|
this.rebuild();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Reimplement the multiselect as a custom element
What i really set off on was to refactor the multiselect’s x-data
context to a separate JavaScript file.
I did not see the need at first, thinking that it would not matter
because it was used only in a template and i was not duplicating the
code in my files. However, i then realized that having the context
in the template means the visitor has to download it each and every time
it accesses a form with a multiselect, even if nothing changed, and,
worse, it would download it multiple times if there were many
multiselect controls.
It makes more sense to put all that into a file that the browser would
only download and parse once, if the proper caching is set.
Once i realized that, it was a shame that AlpineJS has no way to do
the same for the HTML structure[0], for the exact same reasons: not
wanting to download many times the same extra <template> and other
markup required to build the control for JavaScript users. And then i
remembered that this is supposed to be custom element’s main selling
point.
At first i tried to create a shadow DOW to replace the <select> with
the same <div> and <ul> that i used with Alpine, but it turns out that
<select> is not one of the allowed elements that can have a shadow root
attached[0].
Therefore, i changed the custom element to extend the <div> for the
<select> and <label> instead—the same element that had the x-init
context—, but i would have to define or include all the styles inside
the shadow DOM, and bring the lang attribute, for it to look like it
did before. Out with the shadow DOM, and modify the <div>’s contents
instead.
At this point the code was so far removed from the declarative way that
AlpineJS promotes that i did not see much value on using it, except for
its reactivity. But, given that this is such a small component, at the
end decided to write it all in plain JavaScript.
It is more code, at least looking only at the code i had to write, but
i love how i only have to add an is="numerus-multiselect" attribute to
HTML for it to work.
[0]: https://github.com/alpinejs/alpine/discussions/1205
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
|
|
|
|
customElements.define('numerus-multiselect', Multiselect, {extends: 'div'});
|
2023-03-19 22:11:40 +00:00
|
|
|
|
customElements.define('numerus-tags', Tags, {extends: 'div'});
|
2023-03-20 12:09:52 +00:00
|
|
|
|
|
2023-03-26 12:06:26 +00:00
|
|
|
|
let savedTitle = '';
|
2023-03-20 12:09:52 +00:00
|
|
|
|
|
|
|
|
|
htmx.onLoad((target) => {
|
|
|
|
|
if (target.tagName === 'DIALOG') {
|
|
|
|
|
const details = document.querySelectorAll('details[open]');
|
|
|
|
|
for (const detail of details) {
|
|
|
|
|
detail.removeAttribute('open');
|
|
|
|
|
}
|
2023-03-26 12:06:26 +00:00
|
|
|
|
savedTitle = document.title;
|
|
|
|
|
document.title = target.querySelector('h2').textContent + ' — ' + savedTitle.substring(savedTitle.indexOf("—") + 1);
|
2023-03-20 12:09:52 +00:00
|
|
|
|
target.showModal();
|
|
|
|
|
const button = target.querySelector('.close-dialog');
|
|
|
|
|
if (button) {
|
|
|
|
|
button.addEventListener('click', () => {
|
|
|
|
|
htmx.trigger(target, 'closeModal');
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
Trigger filter form on change and search, as well as submit as before
Changed the invoice number field’s type to search to add the delete icon
on Chromium. Firefox does not add that icon, but i do not care; it is
still better that type="text".
Had to emit the change event to the numerus-tag field, otherwise the
form would not detect the change.
I also can not use keyup as a trigger because the changed modifier can
not be used in the <form>, as nothing ever changes, i do not know how to
trigger the form from children (i.e., data-hx-trigger on the <input>
does nothing), and i can not trigger for just any keyup, or i would
make the request even if they only moved the cursor with the arrow keys,
which is very confusing as Firefox resets the position (this may be due
the fact that i reload the whole <main>, but still).
2023-04-03 10:45:15 +00:00
|
|
|
|
htmx.on('htmx:configRequest', function (e) {
|
2023-03-31 11:01:26 +00:00
|
|
|
|
const element = e.detail.elt;
|
|
|
|
|
if (element && element.nodeName === 'FORM') {
|
|
|
|
|
let submitter = e.detail.triggeringEvent.submitter;
|
|
|
|
|
if (submitter) {
|
|
|
|
|
const action = submitter.attributes['formaction'];
|
|
|
|
|
if (action && action.value) {
|
|
|
|
|
e.detail.path = action.value;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
2023-03-20 12:09:52 +00:00
|
|
|
|
htmx.on('closeModal', () => {
|
|
|
|
|
const openDialog = document.querySelector('dialog[open]');
|
|
|
|
|
if (!openDialog) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
openDialog.close();
|
|
|
|
|
openDialog.remove();
|
2023-03-26 12:06:26 +00:00
|
|
|
|
document.title = savedTitle;
|
2023-03-20 12:09:52 +00:00
|
|
|
|
});
|
2023-03-25 00:56:26 +00:00
|
|
|
|
|
|
|
|
|
htmx.on(document, 'alpine:init', () => {
|
|
|
|
|
Alpine.data('snackbar', () => ({
|
|
|
|
|
show: false, toast: "", toasts: [], timeoutId: null, init() {
|
|
|
|
|
htmx.on('htmx:error', (error) => {
|
|
|
|
|
this.showError(error.detail.errorInfo.error);
|
|
|
|
|
});
|
|
|
|
|
},
|
|
|
|
|
showError(message) {
|
|
|
|
|
this.toasts.push(message);
|
|
|
|
|
this.popUp();
|
|
|
|
|
},
|
|
|
|
|
popUp() {
|
|
|
|
|
if (this.toasts.length === 0) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (this.show) {
|
|
|
|
|
this.dismiss();
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (this.toast !== "") {
|
|
|
|
|
// It will show after remove calls popUp again.
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
this.toast = this.toasts[0];
|
|
|
|
|
this.show = true;
|
|
|
|
|
this.timeoutId = setTimeout(this.dismiss.bind(this), 4000);
|
|
|
|
|
},
|
|
|
|
|
dismiss() {
|
|
|
|
|
if (!this.show) {
|
|
|
|
|
// already dismissed
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
this.show = false;
|
|
|
|
|
clearTimeout(this.timeoutId);
|
|
|
|
|
this.timeoutId = setTimeout(this.remove.bind(this), 350);
|
|
|
|
|
},
|
|
|
|
|
remove() {
|
|
|
|
|
clearTimeout(this.timeoutId);
|
|
|
|
|
this.toasts.splice(0, 1);
|
|
|
|
|
this.toast = "";
|
|
|
|
|
this.popUp();
|
|
|
|
|
},
|
|
|
|
|
}));
|
|
|
|
|
});
|