I've been very curious about this as well mostly because you can really nail the LoC paradigm. I'm trying to make each html fragment I'm loading in as self contained as possible. I also think it has a chance to keep the mess of CSS I'm usually left with in check.

Hi, I built this cool nocode tool, using Htmx and Django. Checkout a little demo: Think of Liki as smart links for simpler interactions. Feedback welcome !

Hi, I've mosquitto server with configured websocket. It's secured by login and password. I tried connect from htmx websocket extension but no luck. Is ws-connect="login:password@localhost:8080/topic" is correct sentece order? Is htmx websocket manage login credential?

Is it possible to target a collection of elements and swap them with different collection from response?

I read carefully several of Carson's essays about Restful APIs, HATEOAS, ... I also watched a few of his videos. A huge thank you for showing us what RESTful was meant to be and how htmx can be used to achieve that. I have a question though about the API part. I think I understand how serving HTML in the response is superior to something like JSON. What I now wonder is how a server should offer "data" to 3rd parties. Say I have a website with Weather forecasts. Its API servers HTML fragments allowing me to create nice webpages. If a 3rd party website would like to ingest some weather data - let's imagine they have some Machine Learning algorithm that consume among other things weather data - how would they achieve that? If they connect to my Restful API, they will receive HTML. Should they use some webscraping libraries to extract the data they're looking for? Or should the weather website API also serve JSON response (or whatever format but not RESTful) for non-human users? The webscraping sounds fragile. If the API changed its HTML structure, a human could easily adapt. A 3rd party client would have a harder time to deal with it I suppose.

Thank you @gorgeous-airport-54386 That's indeed a great point. So I understand that the server would still be able to serve JSON for these type of clients? I guess my question really is: should third parties request JSON for data?

They can request whichever format is most useful

You could also use https://microformats.org to make your HTML more machine-readable

Thank you for your input! It's a long question for a short and to-the-point answer. 👍 I'll have a look at microformats.

quick take (was thinking about this earlier) I think shoe-horning a JSON API and hypermedia API together at the same end points hasn't worked out that well. It works for simple cases, but the shape of the hypermedia API is driven by UI needs, whereas a JSON API is driven by the requirement of satisfying arbitrary clients (expressiveness, regularity, etc.). So I'm increasingly inclined to say split them and that the Accept header hasn't turned out to be as useful as expected. Just my opinion. Essay kinda related: https://htmx.org/essays/hypermedia-apis-vs-data-apis/

TLDR: I'd lean towards splitting your JSON API and your hypermedia (HTML) API up.

Thank you very much @mysterious-toddler-20573 for sharing your thoughts on this! I'm happy to read that you would still provide some sort of APsI to satisfy other types of clients - here using a JSON API. I can imagine indeed how the hypermedia API could quickly get very different end points compared to the JSON API as they have different needs. That was my concern in case we wanted to use the hypermedia API to serve data to 3rd parties. If the UI needs to change, the API endpoints could change. But that would break data consumers of the API. As such, I think your advise to segregate them might make a lot of sense. I had read the essay you linked which kind of brought me to this question. I will probably re-read it on the context of what has been discussed here.

I almost always make different endpoints for each (type of) client.

Otherwise coordinating changes becomes a herculean task, specially since some of the clients can be mobile apps

hx-target and hx-select inheritance is really messing up with my code. It's not working. How do I make them not inherit?

Oh yeah, I found hx-disinherit ❤️

@gorgeous-ghost-95789 How does preload extension works? I use it with 'mouseover', it fires GET request on hover, but then on click the request is fired again.

Event on website htmx.org, the navigation is implemented with preload extension, but it actually makes two requests(one on mouseover and second on click). I see no point in the extension itself. The behaviour that I expect is: - On mouseover fire first request - On click swap the html immediately and fire the second request How to get this behaviour? @gorgeous-ghost-95789

hi, I am new to HTMX (although "old" to React to see the beauty of HTMX) I have a question - on a page there's a link with will load detail of current context and modify the URL in the browser - like /order and link points to /order/currentstatus the "HTMX request" will contain only ask for status but what if I navigate directly to /order/currentstatus (or open the URL in new tab)? I know I can differentiate between HTMX request and "plain old HTML request" by looking at HX-Request request header, but what should I do in that case - return /order response? but how will I include the /currenstatus part?

hx-disinherit doesn't work for hx-include for some reason.

Also, preload extension doesn't support hx-vals. Because of that, first request is going without these params, the second one goes with and it breaks browser caching because of different params.

won't the link include something like order/ID/status or some query param(s) for the order? in which case you could redirect back to the order page

or you could render out what the page would look like if you had clicked the link

hx request returns a fragment but going to the link directly returns the whole page

For anyone who has been trying to work with Shoelace and htmx together (or uses the search button in the future), here is a crude workaround:

`html
<form ... hx-vals="javascript:{checked: document.querySelector("sl-checkbox").checked}">
  <sl-checkbox></sl-checkbox>
  <sl-button type="submit></sl-button>
</form>

I stopped experimenting before I went too far down the rabbit hole of formdata events and deferring htmx load until after shoelace had added its event handlers; I'm not sure I know quite what I"m doing at that point.

I might redirect back to /order, it sounds like a "normal" request for /order/currentstatus isn't a good representation for the order, so the user should be redirected to a URL that is (if I'm understanding correctly)

\> I'm not sure I know quite what I"m doing at that point. welcome to the club!

maybe /order/currentstatus was not the best example 🙂

I'm pretty sure HTMX has the valid form types hardcoded by name - select, button, input, etc. I've been using hx-include to get the values. I assume we could write a plugin to make it more native but I haven't gotten around to it yet 😅

html
<sl-button 
    variant="primary" 
    hx-patch="/urlnamehere"
    hx-swap="outerHTML"
    hx-target="closest form"
    hx-include="sl-input">
        Save
        <sl-spinner class="htmx-indicator"></sl-spinner>
</sl-button>