https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • g
    I'm happy to take a shot at it. I posted some comments to your gist. TL;DR - Yes. Yes. Yes + questions on syntax and future direction.
  • g
    For now, I'll get started with a spike, then cry for help when I get lost in the woods.
  • t
    > This person offered to help: https://twitter.com/kerns @User I know him!
  • t
    @mysterious-toddler-20573 My family had a few medical emergencies over the past 3 days, sorry that de-railed our twitter DM dialog. I am really interested to have @User's take on the diagram(s) if he is willing to act as a sounding board for some of these ideas. I feel like if Ben understands it and could help explain it to me, I will be properly briefed to create the strongest possible visualisation.
  • m
    💯
  • h
    Hi all. Just found this Discord, so I think it's better to continue this Twitter thread here 🙂 https://twitter.com/functionalbytes/status/1304407073732603905
  • h
    In essence, can or should the 
    hx-ext
    attribute be used for adding any logic to elements, both on initial page load and after a swap? Or is it only for extending htmx's functionality, and should I use something like Stimulus?
  • h
    I really like the idea of htmx, and one less library would be nice
  • h
    Just did some testing, maybe Stimulus complements htmx nicely. Still interested in your opinions though.
  • h
    Another question, say I have the following layout:
  • h
    When the form (yellow) is submitted, and all is ok, the main content (green) should be swapped. But if the form input is incorrect, only the form content should be swapped - with some error messages - leaving the other dynamic content (orange) alone. Is this possible?
  • m
    You can use an htmx extension to listen to any event, not just htmx-namespaced events.
  • m
    You can also use an OOB swap to update multiple elements on the page in a single request.
  • m
  • h
    > You can use an htmx extension to listen to any event, not just htmx-namespaced events. As long as the extension is triggered right? Which does not happen on page load time if the element does not contain a hx-, hx-sse or hx-ws, as far as I can tell.
  • h
    > You can also use an OOB swap Do you propose to use OOB swap the main content?
  • m
    Yes, I think you are right, because HTMX is for triggering requests, if you don't have any directive to trigger a request, then it won't be initialized for any given element and children.
  • m
    You can use the OOB swap to update the dynamic content when the request is successful. The main content can be swapped normally.
  • m
    By providing IDs in your response and the OOB swap directive, you can choose where different parts the response are swapped on the page.
  • h
    Thanks, I understand, is this the idiomatic way of doing such "main content" updates?
  • m
    I am no htmx expert. Just trying to provide some ideas. You can also replace the entire main content area on every request and include/exclude the parts you want on the server side. I guess it also depends on how you are rendering the main content on the initial page load. If these are separate "components", then use OOB. If it's all rendered together, then replace the entire main content on each request. There's more than one way of doing this.
  • m
    Hi @User For question 1, I would say that an extension/plugin would make sense if you wanted to contribute a general Stimulus/htmx plugin that makes stimulus "just work". If you are doing it as a user, however, and just want to integrate the two yourself, I would lean towards using events. An important thing to understand about the 
    htmx.load
    event is that it is triggered only on the top node of new content, and you are expected to process all the content below the new node yourself.
  • m
    For the second issue, it's a bit tricky in htmx. htmx assumes statelessness, as with the original vision for the web, so ideally your form would target the outer "Main Content" element and replace it every time, even the other dynamic content. Reality being what it is, however, the right thing here is for the form to target the inner "Form Content" and when a successful form submission is made, target the Main Content with an out of bound swap by ID.
  • m
    I think we could do a better job of selecting the response target, maybe offer an 
    HX-Retarget
    response header
  • m
    @User one comment on this: > To clarify, I expected to see a htmx:load or htmx:processedNode event when the page is loaded, as to hydrate the elements with the extension's logic. We don't trigger an event on every node for performance reasons. We actually run selectors on new content to pick out the htmx-specific nodes to process. So it falls to the developer to pick out nodes that need to be initialized in the new content for processing. I don't really like that: I would prefer to iterate over every node in the DOM, but there were performance complaints in large pages.
  • m
  • m
  • m
    ☝️ some comments on the implementation
  • m
    for sse
  • m
    it seems to me like with a few small refactors you could implement what we have been discussing without a large code change
1...272829...1146Latest