https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • g
    Not the same, but related -- I'm working on a real-time server that uses SSE to push changes to specific pages / page fragments when resources update on the back end. My use case definitely requires a server component that monitors assets, but the result is fantastic.
  • g
    From what @mysterious-toddler-20573 said, it seems like you could write an extension that listens for (and tracks) some sort of server version -- probably passed in the HTTP header. If this value changes, then your extension could trigger an event (named OMG_NEW_SERVER_VERSION) somewhere on your root DOM node. Then, your HTMX code could just listen for this event, something like 
    <body hx-get="/the-app" hx-trigger="OMG_NEW_SERVER_VERSION">
    . I did something vaguely like this in an old Angular app, but building it on top of HTMX would be much cleaner.
  • g
    (in case it's not clear in my example, anything inside the tag would be swapped out by HTMX when that event fires. That should include any stylesheets that are contained within the body)
  • u
    If I understand correctly: htmx has per definition (per concept) no template mechanism, meaning that all structural (declarative) information has to come from the server. Example: to fill a table with data from server, just a JSON list of entities is not enough, the list has to carry etc too?
  • m
    Hi @User yes, htmx expects the HTTP transport to be HTML, rather than JSON. However, there is a client-side template extension if you wish to use JSON instead: https://htmx.org/extensions/client-side-templates/
  • u
    ah this is helpful 😀
  • u
    One point that I really like at htmx is got rethink web, its basic ideas and the principle of simplicity
  • g
    Exactly. Work with native elements (like DOM Nodes, HTTP, and Events) and fill in all of the connections between them that weren't already completed in the original browser specs.
  • m
    yep! The goal of htmx is to complete HTML as a hypertext, so we can build nice UX within the original model of the web 🙂
  • t
    Hi! I have a question about transitions. Is there some equivalent to unpoly's up-transition ="move-left"?
  • t
    I'd love to choose transitions in links
  • m
    Hi Charles, no not out of the box. That would need to be accomplished with CSS animations in htmx.
  • m
    and, actually on thinking on it, you'd need to write an exension for that :/
  • m
    We don't keep both pieces of content in the DOM at the same time, which is what you would need
  • a
    > yep! The goal of htmx is to complete HTML as a hypertext, so we can build nice UX within the original model of the web 🙂 @User one limit of this approach I think is that GUI code is distributed and not in a single place (compared for example with Alpine, vue, etc approach)... am i right?
  • g
    Meh? The Angular apps I built still spread code over a wide area. Think models, views, controllers, components... not to mention a duplicate of all that to generate JSON/REST endpoints.
  • g
    I don’t know that HTMX spreads code any more or less that other approaches. I do think it helps to move UI code into a more consistent place. HTML for structure, and JavaScript of client-side widgets (like that pesky calendar widget everyone rebuilds)
  • g
    What do you think, @ancient-soccer-8576?
  • u
    Hi, I'am playing with htmx and loving it. Congrats! One question I wondering, what's the best practices for history/bookmarks. Imagine I select a resource in a list so I issue an hx-get /resource/123, I can push /resource/123 in the URL. If it's bookmarked, the /resource/123 is in fact only the HTML fragment. How do one works around this usually?
  • m
    @User I typically will do a server side header check to see if it is an HTMX request or not, and if it is not I will render the entire page
  • m
    using the standard application layout (this is in rails terms, ymmv)
  • u
    Exactly what I was looking into right now, is HX-Current-URL is safe check?
  • m
    @User The GUI code is in one place, in that it is all in HTML, but the glue code between the client and the server code is more split up, if I'm understanding you
  • m
    @ancient-soccer-8576 I wrote an essay on Locality of Behavior: https://htmx.org/essays/locality-of-behaviour/
  • m
    I think that htmx helps with that. However, if you are used to something that abstracts the serverside/clientside distinction away, then it is going to seem like the opposite
  • m
    Something like livewire, or whatever, where you don't have (in theory) to worry about the distinction between the client side and server side
  • m
    in htmx, you still do need to think in terms of HTTP requests and the more traditional stateless transformation model of the web
  • m
    @User HX-Request will always be "true" for htmx requests see https://htmx.org/reference/#request_headers
  • a
    what i am struggling is for example if my http request will need to update more GUI objects placed in different places on the page...
  • m
    Ah, yes. Classic problem with htmx
1...676869...1146Latest