The Renaissance of server side rendering with Alpine and HTMX(alexmercedcoder.medium.com)
alexmercedcoder.medium.com
The Renaissance of server side rendering with Alpine and HTMX
https://alexmercedcoder.medium.com/the-renaissance-of-server-side-rendering-with-alipine-and-htmx-reactivity-with-minimal-js-809e5442480f
9 comments
Hi There.
For 1, you probably want to either trigger js events using the various `HX-Trigger*` headers: https://htmx.org/reference/#response_headers or consider creating a small extension based on the client-side templates extension: https://htmx.org/extensions/client-side-templates/
For 2, I think this was a classic tone-on-the-internet issue. The 7b rule is mainly a joke/meme where we (the htmx discord) tell old-timers who want something "Hey, great idea. Now you have to implement it." For a newbie this might come across as "f you, u fix it" but that's not the underlying message.
We are happy to take feature requests and do try to implement them (e.g. I just added request synchronization via the `hx-sync` attribute in 1.7.0, based on a user request: https://htmx.org/attributes/hx-sync/)
That said, the htmx code base is relatively small and simple to deal with, and I do highly encourage people to dig in and see if they can fix their issues or, especially, add the functionality with an extension. I want the code to be truly a public good: BSD, anyone can read and understand it, we don't thrash the code base around a lot.
For 1, you probably want to either trigger js events using the various `HX-Trigger*` headers: https://htmx.org/reference/#response_headers or consider creating a small extension based on the client-side templates extension: https://htmx.org/extensions/client-side-templates/
For 2, I think this was a classic tone-on-the-internet issue. The 7b rule is mainly a joke/meme where we (the htmx discord) tell old-timers who want something "Hey, great idea. Now you have to implement it." For a newbie this might come across as "f you, u fix it" but that's not the underlying message.
We are happy to take feature requests and do try to implement them (e.g. I just added request synchronization via the `hx-sync` attribute in 1.7.0, based on a user request: https://htmx.org/attributes/hx-sync/)
That said, the htmx code base is relatively small and simple to deal with, and I do highly encourage people to dig in and see if they can fix their issues or, especially, add the functionality with an extension. I want the code to be truly a public good: BSD, anyone can read and understand it, we don't thrash the code base around a lot.
Firstly, thank you for your response.
This is not really the forum for this, but for 1, I don't see how this will help.
I get a response from the server of <li>1</li><li>5</li>, and I want to add [1,5] to an array, and then modify them to <li>one</li><li>five</li> before insertion. How would I do that?
2. Lack of internet meme knowledge, but still perhaps worth thinking about changing?
This is not really the forum for this, but for 1, I don't see how this will help.
I get a response from the server of <li>1</li><li>5</li>, and I want to add [1,5] to an array, and then modify them to <li>one</li><li>five</li> before insertion. How would I do that?
2. Lack of internet meme knowledge, but still perhaps worth thinking about changing?
For 1, you would probably want to follow the code here for client side templates:
https://unpkg.com/[email protected]/dist/ext/client-side-templa...
in particular taking advantage of the `transformResponse` extension point in htmx. It would not be too much work to allow a function call to transform and extract information from the `text` variable, which is the raw response text.
For 2, I have updated the FAQ to make it clear that it's a joke.
https://unpkg.com/[email protected]/dist/ext/client-side-templa...
in particular taking advantage of the `transformResponse` extension point in htmx. It would not be too much work to allow a function call to transform and extract information from the `text` variable, which is the raw response text.
For 2, I have updated the FAQ to make it clear that it's a joke.
Isn't the Alpine + HTMX combo intended to plug this gap?
HTMX handles situations where you just need interactions to replace parts of the page via back-end logic.
Alpine is there as a similar declarative layer for stuff which requires client-side logic.
(caveat - It's a while since I did webdev but I've been a long-term fan of Intercooler - the precursor to HTMX. Carlton has been banging this drum for many years and I find myself very much in tune with his views on where front-end dev went wrong)
HTMX handles situations where you just need interactions to replace parts of the page via back-end logic.
Alpine is there as a similar declarative layer for stuff which requires client-side logic.
(caveat - It's a while since I did webdev but I've been a long-term fan of Intercooler - the precursor to HTMX. Carlton has been banging this drum for many years and I find myself very much in tune with his views on where front-end dev went wrong)
Even after reading the tutorial I am not sure when Alpine would help, but either way - I am not looking for Alpine, Angular (ugh) or diet vanilla (um..)
I am looking to post-process our input just a little, or trying to add content to state arrays or whatever.
I am looking to post-process our input just a little, or trying to add content to state arrays or whatever.
The first item in the FAQ:
> "What is rule 7b?"
> > If you suggest something, you build it.
If any @htmx devs read this - maybe rewrite to suggest that you are always open to ideas or even criticism, but no guarantees that things will be addressed.
And that you are always happy to get pull requests if we know enough, and are brave enough, to try fixing things ourselves.
> "What is rule 7b?"
> > If you suggest something, you build it.
If any @htmx devs read this - maybe rewrite to suggest that you are always open to ideas or even criticism, but no guarantees that things will be addressed.
And that you are always happy to get pull requests if we know enough, and are brave enough, to try fixing things ourselves.
Personally, I find this a lot harder to reason about than views reacting to state changes and that state is the single source of truth of the UI
> Several framework specific solutions have come to existence to give server-side templating more client side power, in particular:
> Ruby/Rails => TurboLinks/Hotwire
Hotwire is not framework specific. E.g. hotwired/turbo is just a JS library that allows for progressive enhancement in basically any web application that renders HTML. I use it in Go and I love it!
> Ruby/Rails => TurboLinks/Hotwire
Hotwire is not framework specific. E.g. hotwired/turbo is just a JS library that allows for progressive enhancement in basically any web application that renders HTML. I use it in Go and I love it!
1. There is no simple way to have it handle the response with JS. You could add a global listener to the htmx response and somehow handle the response and overwrite the default HTMX application handling. I could not figure out how, and besides, it is global, not per element.
I want `hx-preinsert="myfunc"` where myfunc gets the element and response, and the html it returns will be handled as if it were gotten from the server
myfunc(callingElement, serverResponse){ return modifiedServerResponse }
I spoke to some other devs and they had the same issue. Which brings me to the second issue.
2. They say quite clearly, "we don't want any feature requests, suggestions, or bug requests unless you are interested in implementing it yourself."
I spoke to someone on chat about what I thought was a bug, and got a response "feel free to fix it, or shut up". Don't know who I spoke to, but still..
So, it could be that everyone is using things like TurboLinks just because of obvious things. Which is discouraging, as it is really a pleasure to use.
EDIT: It no longer says you have to write your own fixes. Great!