I mainly did it for the new hx-on attribute, to click the update
button on recompute, but it does not seem to work as i think it does.
Anyway, there are some fixed bugs.
From the release announcement[0]:
## New Features
* Support for view transitions, based on the experimental View
Transitions API currently available in Chrome 111+ and coming to
other browsers soon.
* Support for “naked” hx-trigger attributes, where an hx-trigger is
present on an element that does not have an hx-get, etc. defined on
it. Instead, it will trigger the new htmx:triggered event, which
can be responded to via your preferred scripting solution.
* Support for generalized inline event handling via the new hx-on
attribute, which addresses the shortcoming of limited onevent
properties attributes in HTML.
## Improvements & Bug fixes
* A memory leak fix by @croxton
[0]: https://htmx.org/posts/2023-04-11-htmx-1-9-0-is-released/
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.
I am not sure if, at the end, all pages that now use
mustRenderAppTemplate will be replaced with mustRenderMainTemplate,
but for now i keep them separate to know which routes are already
“boosted”.
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
I had in the product edit page only because it was easier to test there
while i was developing it, but it is something that should be done for
all select[multiple], of course.
I removed the whole x-cloak thing because i am not sure what would
happen if i do something wrong and Alpine can not initialize the
multiselect; probably show nothing to the user. Now it shows the
native select a fraction of a second, but if i fuck it up at least the
user can still use the app.
This is just to set the correct `lang` attribute on the HTML, so that
text readers can do its job and the `(optional)` suffix of labels gets
the correct ”translation”.
I have been thinking about that, and it does not make that much sense to
have the titles in the Go source anymore: most of them are static text
that i have to remember to set in the controller each time, and when
the time come i have to face a dynamic title i am sure i will manage
with only the template capabilities—worst comes worst, i can always
define a function.
On the other hand, there is no way i can define a template without its
title and i know that everytime that template is used, no matter what
controller rendered it, it will always have that title.
jordi fita mas