tandem
/
numerus
2
0
Fork 0
Code Issues 39 Pull Requests Packages Projects 1 Releases 1 Wiki Activity
numerus/web/static/numerus.js

551 lines
17 KiB
JavaScript
Raw Normal View History

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 = '';
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
2023-03-18 06:17:28 +00:00
this.highlighted = 0;
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() {
Remove document and window event handlers when removing custom elements I realized that the event handlers that i was setting when creating the tags input and the multi-select controls were not removed just because these elements are no longer in the document, and kept firing again and again. I no longer can use an anonymous function, because removeEventListener would not match it with the one passed to addEventListener. I also have to bind the handler to `this` in order to keep having access to the object, and, again, can not do it in the call to addEventListener, or i would get a different function each time. I added the check to see if the element is connected inside the connectedCallback because the documentation warns that this callback “may be called once your element is no longer connected”[0], and i understood it to mean that the connected and disconnected callbacks could be called our of order, thus it would be possible to add event listeners that would not be removed—again. I am not actually sure where i have to do the same for the rest of the “internal” events. [0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements#using_the_lifecycle_callbacks
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();
}
}
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
if (this.initialized) {
this.onClickHandler = () => this.toggle();
this.tags.addEventListener('click', this.onClickHandler);
this.onSearchInputHandler = (e) => {
this.open();
this.filter(e.target.value);
}
this.onSearchKeydownHandler = (e) => {
switch (e.code) {
case "Enter":
e.preventDefault();
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();
}
break;
case "Backspace":
if (e.target.value === '') {
this.deselectLast();
}
break;
case "Escape":
this.close();
break;
}
};
this.search.addEventListener('input', this.onSearchInputHandler);
this.search.addEventListener('keydown', this.onSearchKeydownHandler);
this.onFocusOutHandler = (e) => {
if (this.contains(e.target)) return;
if (!e.target.isConnected) return;
this.close();
}
window.addEventListener('focusin', this.onFocusOutHandler);
document.addEventListener('click', this.onFocusOutHandler);
Fix adding empty tag on focus out from element For some reason, i was looking at the value of the focus’ **target**, which is not my search field at all, but whatever control the focus changes **to**. It that new control is an input with value, then it created a new tag with whatever my search field had, which could be the empty string.
2023-04-11 08:23:32 +00:00
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
this.rebuild()
}
Remove document and window event handlers when removing custom elements I realized that the event handlers that i was setting when creating the tags input and the multi-select controls were not removed just because these elements are no longer in the document, and kept firing again and again. I no longer can use an anonymous function, because removeEventListener would not match it with the one passed to addEventListener. I also have to bind the handler to `this` in order to keep having access to the object, and, again, can not do it in the call to addEventListener, or i would get a different function each time. I added the check to see if the element is connected inside the connectedCallback because the documentation warns that this callback “may be called once your element is no longer connected”[0], and i understood it to mean that the connected and disconnected callbacks could be called our of order, thus it would be possible to add event listeners that would not be removed—again. I am not actually sure where i have to do the same for the rest of the “internal” events. [0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements#using_the_lifecycle_callbacks
2023-04-09 22:05:29 +00:00
}
disconnectedCallback() {
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
if (this.initialized) {
this.removeTags();
this.options.innerHTML = '';
document.removeEventListener('click', this.onFocusOutHandler);
window.removeEventListener('focusin', this.onFocusOutHandler);
this.onFocusOutHandler = null;
this.search.removeEventListener('keydown', this.onSearchKeydownHandler);
this.search.removeEventListener('input', this.onSearchInputHandler);
this.onSearchInputHandler = null;
this.onSearchKeydownHandler = null;
this.tags.removeEventListener('click', this.onClickHandler);
this.onClickHandler = null;
}
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.search = document.createElement('input');
this.tags.append(this.search);
this.search.id = this.select.id;
this.select.removeAttribute('id');
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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
// Must come after the search input
this.tags.append(this.label);
this.options = document.createElement('ul');
this.append(this.options);
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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');
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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();
}
rebuildOptions() {
this.options.innerHTML = '';
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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);
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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));
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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
}
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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) {
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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) {
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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();
}
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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;
}
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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();
}
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
removeTags() {
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.tags.querySelectorAll('.tag').forEach((tag) => tag.remove());
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
}
rebuildTags() {
this.removeTags();
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
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';
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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');
Add missing ARIA attributes and keyboard controls to multiselect I use MDN’s documentation[0] as guid for both. [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
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();
}
}
Start the tag input custom element This is more or less the same as a multiselect, except that now it adds a list of string element that you write into the search element. It is supposed to fetch a list of tag suggestions from the server, but i have not implemented it yet.
2023-03-19 22:11:40 +00:00
class Tags extends HTMLDivElement {
constructor() {
super();
this.initialized = false;
this.tags = [];
}
connectedCallback() {
Remove document and window event handlers when removing custom elements I realized that the event handlers that i was setting when creating the tags input and the multi-select controls were not removed just because these elements are no longer in the document, and kept firing again and again. I no longer can use an anonymous function, because removeEventListener would not match it with the one passed to addEventListener. I also have to bind the handler to `this` in order to keep having access to the object, and, again, can not do it in the call to addEventListener, or i would get a different function each time. I added the check to see if the element is connected inside the connectedCallback because the documentation warns that this callback “may be called once your element is no longer connected”[0], and i understood it to mean that the connected and disconnected callbacks could be called our of order, thus it would be possible to add event listeners that would not be removed—again. I am not actually sure where i have to do the same for the rest of the “internal” events. [0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements#using_the_lifecycle_callbacks
2023-04-09 22:05:29 +00:00
if (!this.isConnected) {
return;
}
Start the tag input custom element This is more or less the same as a multiselect, except that now it adds a list of string element that you write into the search element. It is supposed to fetch a list of tag suggestions from the server, but i have not implemented it yet.
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();
}
}
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
if (this.initialized) {
this.onSearchKeydownHandler = (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;
}
}
this.search.addEventListener('keydown', this.onSearchKeydownHandler);
this.onFocusOutHandler = (e) => {
if (this.contains(e.target)) return;
Execute “focus out” handler in tag input when clicking any other element Apparently i was only testing that control with tab, because clicking on any other non-focusable element (e.g., a table row) it did not add the new tag and would not dispatch the “numerus-tag-out” custom element, which is why i have seen it now. This is equivalent to AlpineJS’s @click.outside, and i was already using it for the multiselect dropdown. The isConnected check is because i probably found some cases in the dropdown’s handler, but i can not remeber now, but since AlpineJS does it too, i guess it is important.
2023-04-12 09:59:45 +00:00
if (!e.target.isConnected) return;
Fix adding empty tag on focus out from element For some reason, i was looking at the value of the focus’ **target**, which is not my search field at all, but whatever control the focus changes **to**. It that new control is an input with value, then it created a new tag with whatever my search field had, which could be the empty string.
2023-04-11 08:23:32 +00:00
if (this.search.value && this.search.value.trim() !== '') {
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
this.createTag();
}
Allow editing invoice tags inline from the index table I use the same pattern as HTMx’s “Click to Edit” example[0], except that my edit form is triggered by submit and by focus out of the tags input. I could not, however, use the standard focus out event because it would also trigger when removing a tag with the mouse, as for a moment the remove button has the focus and the search input dispatches a bubbling focusout. I had to resort to a custom event for that, but i am not happy with it. The autofocus attribute seems to do nothing in this case, so i need to manually change the focus to the new input with JavaScript. However, this means that i can not use the same input ID for all the forms because getElementById would always return the first in document order, changing the focus to that same element and automatically submit the form due to focus out. That’s why in this form i append the invoice’s slug to the input’s ID. Finally, this is the first time i am using an HTMx-only solution and i needed a way to return back just the HTML for the <td>, without <title>, breadcrumbs, or <dialog>. In principle, the template would be the “layout”, but then i would need to modify everything to check whether the template file is empty, or something to that effect, so instead i created a “standalone” template for these cases. [0]: https://htmx.org/examples/click-to-edit/
2023-04-11 08:46:27 +00:00
this.dispatchEvent(new CustomEvent("numerus-tags-out", {bubbles: true}))
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
};
window.addEventListener('focusin', this.onFocusOutHandler);
Execute “focus out” handler in tag input when clicking any other element Apparently i was only testing that control with tab, because clicking on any other non-focusable element (e.g., a table row) it did not add the new tag and would not dispatch the “numerus-tag-out” custom element, which is why i have seen it now. This is equivalent to AlpineJS’s @click.outside, and i was already using it for the multiselect dropdown. The isConnected check is because i probably found some cases in the dropdown’s handler, but i can not remeber now, but since AlpineJS does it too, i guess it is important.
2023-04-12 09:59:45 +00:00
document.addEventListener('click', this.onFocusOutHandler);
Remove document and window event handlers when removing custom elements I realized that the event handlers that i was setting when creating the tags input and the multi-select controls were not removed just because these elements are no longer in the document, and kept firing again and again. I no longer can use an anonymous function, because removeEventListener would not match it with the one passed to addEventListener. I also have to bind the handler to `this` in order to keep having access to the object, and, again, can not do it in the call to addEventListener, or i would get a different function each time. I added the check to see if the element is connected inside the connectedCallback because the documentation warns that this callback “may be called once your element is no longer connected”[0], and i understood it to mean that the connected and disconnected callbacks could be called our of order, thus it would be possible to add event listeners that would not be removed—again. I am not actually sure where i have to do the same for the rest of the “internal” events. [0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements#using_the_lifecycle_callbacks
2023-04-09 22:05:29 +00:00
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
this.rebuild();
}
Remove document and window event handlers when removing custom elements I realized that the event handlers that i was setting when creating the tags input and the multi-select controls were not removed just because these elements are no longer in the document, and kept firing again and again. I no longer can use an anonymous function, because removeEventListener would not match it with the one passed to addEventListener. I also have to bind the handler to `this` in order to keep having access to the object, and, again, can not do it in the call to addEventListener, or i would get a different function each time. I added the check to see if the element is connected inside the connectedCallback because the documentation warns that this callback “may be called once your element is no longer connected”[0], and i understood it to mean that the connected and disconnected callbacks could be called our of order, thus it would be possible to add event listeners that would not be removed—again. I am not actually sure where i have to do the same for the rest of the “internal” events. [0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements#using_the_lifecycle_callbacks
2023-04-09 22:05:29 +00:00
}
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
disconnectedCallback() {
if (this.initialized) {
this.removeTags();
Execute “focus out” handler in tag input when clicking any other element Apparently i was only testing that control with tab, because clicking on any other non-focusable element (e.g., a table row) it did not add the new tag and would not dispatch the “numerus-tag-out” custom element, which is why i have seen it now. This is equivalent to AlpineJS’s @click.outside, and i was already using it for the multiselect dropdown. The isConnected check is because i probably found some cases in the dropdown’s handler, but i can not remeber now, but since AlpineJS does it too, i guess it is important.
2023-04-12 09:59:45 +00:00
document.removeEventListener('click', this.onFocusOutHandler);
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
window.removeEventListener('focusin', this.onFocusOutHandler);
this.onFocusOutHandler = null;
this.search.removeEventListener('keydown', this.onSearchKeydownHandler);
this.onSearchKeydownHandler = null;
Remove document and window event handlers when removing custom elements I realized that the event handlers that i was setting when creating the tags input and the multi-select controls were not removed just because these elements are no longer in the document, and kept firing again and again. I no longer can use an anonymous function, because removeEventListener would not match it with the one passed to addEventListener. I also have to bind the handler to `this` in order to keep having access to the object, and, again, can not do it in the call to addEventListener, or i would get a different function each time. I added the check to see if the element is connected inside the connectedCallback because the documentation warns that this callback “may be called once your element is no longer connected”[0], and i understood it to mean that the connected and disconnected callbacks could be called our of order, thus it would be possible to add event listeners that would not be removed—again. I am not actually sure where i have to do the same for the rest of the “internal” events. [0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements#using_the_lifecycle_callbacks
2023-04-09 22:05:29 +00:00
}
Start the tag input custom element This is more or less the same as a multiselect, except that now it adds a list of string element that you write into the search element. It is supposed to fetch a list of tag suggestions from the server, but i have not implemented it yet.
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');
// Must come after the search input
this.tagList.append(this.label);
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
}
Start the tag input custom element This is more or less the same as a multiselect, except that now it adds a list of string element that you write into the search element. It is supposed to fetch a list of tag suggestions from the server, but i have not implemented it yet.
2023-03-19 22:11:40 +00:00
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
removeTags() {
this.tagList.querySelectorAll('.tag').forEach((tag) => tag.remove());
Start the tag input custom element This is more or less the same as a multiselect, except that now it adds a list of string element that you write into the search element. It is supposed to fetch a list of tag suggestions from the server, but i have not implemented it yet.
2023-03-19 22:11:40 +00:00
}
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}));
}
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
this.removeTags();
Start the tag input custom element This is more or less the same as a multiselect, except that now it adds a list of string element that you write into the search element. It is supposed to fetch a list of tag suggestions from the server, but i have not implemented it yet.
2023-03-19 22:11:40 +00:00
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();
Set the focus back to the search input when removing a tag The idea is that if they removed a tag it is more that possible that they want to continue editing tags.
2023-04-11 08:24:40 +00:00
this.removeTag(tagText);
this.search.focus();
Start the tag input custom element This is more or less the same as a multiselect, except that now it adds a list of string element that you write into the search element. It is supposed to fetch a list of tag suggestions from the server, but i have not implemented it yet.
2023-03-19 22:11:40 +00:00
});
}
}
}
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'});
Start the tag input custom element This is more or less the same as a multiselect, except that now it adds a list of string element that you write into the search element. It is supposed to fetch a list of tag suggestions from the server, but i have not implemented it yet.
2023-03-19 22:11:40 +00:00
customElements.define('numerus-tags', Tags, {extends: 'div'});
Show the profile form in a dialog using HTMx Had to split the actual page content and the breadcrumbs because they do not belong in a dialog. However, i had to change all templates to do that.
2023-03-20 12:09:52 +00:00
Manually update and restore the <title> when showing dialog with HTMx Mostly, the same problem as before: if the document title does not reflect the application’s state, it becomes useless when there are multiple open tabs. In this case, however, i do not know how to tell HTMx to restore the title to how it was before opening the dialog without a new request to the server, that makes no sense when the dialog was closed without any change whatsoever. Thus, i do it with JavaScript on the client side.
2023-03-26 12:06:26 +00:00
let savedTitle = '';
Show the profile form in a dialog using HTMx Had to split the actual page content and the breadcrumbs because they do not belong in a dialog. However, i had to change all templates to do that.
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');
}
Manually update and restore the <title> when showing dialog with HTMx Mostly, the same problem as before: if the document title does not reflect the application’s state, it becomes useless when there are multiple open tabs. In this case, however, i do not know how to tell HTMx to restore the title to how it was before opening the dialog without a new request to the server, that makes no sense when the dialog was closed without any change whatsoever. Thus, i do it with JavaScript on the client side.
2023-03-26 12:06:26 +00:00
savedTitle = document.title;
document.title = target.querySelector('h2').textContent + ' — ' + savedTitle.substring(savedTitle.indexOf("—") + 1);
Show the profile form in a dialog using HTMx Had to split the actual page content and the breadcrumbs because they do not belong in a dialog. However, i had to change all templates to do that.
2023-03-20 12:09:52 +00:00
target.showModal();
const button = target.querySelector('.close-dialog');
if (button) {
Try to remove as many leaky references from event listeners as possible
2023-04-10 21:04:16 +00:00
button.addEventListener('click', (e) => {
htmx.trigger(e.target, 'closeModal');
}, {once: true});
Show the profile form in a dialog using HTMx Had to split the actual page content and the breadcrumbs because they do not belong in a dialog. However, i had to change all templates to do that.
2023-03-20 12:09:52 +00:00
}
}
})
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) {
Put new invoice and edit invoice forms into a dialog In this case i have to use the same id for the dialog content in all pages because, for now, there are a couple of forms that need to replace it on submit—the new/edit form and the product selection form. Unfortunately, HTMx does not have support for `formaction` attribute at this point, so i had to use the workaround described in [0]. [0] https://github.com/bigskysoftware/htmx/issues/623
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;
}
}
}
})
Show the profile form in a dialog using HTMx Had to split the actual page content and the breadcrumbs because they do not belong in a dialog. However, i had to change all templates to do that.
2023-03-20 12:09:52 +00:00
htmx.on('closeModal', () => {
const openDialog = document.querySelector('dialog[open]');
if (!openDialog) {
return;
}
openDialog.close();
openDialog.remove();
Manually update and restore the <title> when showing dialog with HTMx Mostly, the same problem as before: if the document title does not reflect the application’s state, it becomes useless when there are multiple open tabs. In this case, however, i do not know how to tell HTMx to restore the title to how it was before opening the dialog without a new request to the server, that makes no sense when the dialog was closed without any change whatsoever. Thus, i do it with JavaScript on the client side.
2023-03-26 12:06:26 +00:00
document.title = savedTitle;
Show the profile form in a dialog using HTMx Had to split the actual page content and the breadcrumbs because they do not belong in a dialog. However, i had to change all templates to do that.
2023-03-20 12:09:52 +00:00
});
Add a SnackBar to show HTMx errors We do not have any design yet for errors and other notifications, so i followed material design, for now, since we already kind of use their input fields design. This time i decided to use AlpineJS because there is not that much HTML code, and the transitioning is way easier to do in AlpineJS than it would be with plain JavaScript—not to mention the bugs i would introduce.
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();
},
}));
});