https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • t
    if you want to read more into the philosophy of htmx
  • t
    But in essence, servers are very good at serving html. They have been for decades. Browsers are very good at displaying html. There is no need to do the whole converting data to json to pass to the client to then have the client build html with the data when you can just return html to the client.
  • l
    Nice!
  • r
    You can technically use this extension to integrate a templating library with htmx https://htmx.org/extensions/client-side-templates/, which will technically provide support for JSON responses. However, htmx is intended to be used with HTML and, unless you have no control over backend and no way to switch to HTML, you will get way better experience with the standard way (this statement comes from experience)
  • r
    More specifically, these are the issues that I encountered: the need to mix server side templates with client side templates; lack of access to backend features (e.g., localization, formatting, authorization; with ASP.NET core in my case there is no way to use tag helpers) and, therefore, necessity to either reimplement these features by extending client template engine, or to add a field to your response DTOs for every possible usage, which causes your API to explode (and I did both, does not bring joy at all); the need to distribute required templates with your page content, which instantly gets tricky if you use partial updates
  • r
    TLDR: JSON - not fun, use it as last resort
  • m
    maybe the default should be append if absent?
  • b
    I think it depends on intended use case. My initial use case was to build component-ish pages which would include JS (sort of like a Vue SFC concept). So I’d want: * Initial 
    <head>
    to stay mostly unchanged * Ability to add a handful of page-specific elements (script, style) * Have the new script available even on subsequent partial page loads * Some mechanism to remove the page-specific stuff that got dynamically added, so the 
    head
    doesn’t get cluttered as the user clicks around to different “pages” But there might be other use cases, like the default merge seems closer to a wholesale swap of 
    head
    , and I’d guess there’s a reason for that since you’ve been doing this way longer 🙂 So it’s not obvious to me that my use case should be the default. Another idea was a 
    head
    template, so each head swap is the default head template plus whatever head elements are in the response. Or similar could be achieved by keeping everything in the original head, and having a 
    hx-remove-me-next-head-swap
    for all of the page-specific stuff. This one also solves the issue with any other dynamic head changes, like the 
    .html-indicator
    style that gets added (and potentially other libraries could break if they’re doing something similar)
  • b
    I can see conflicting needs though. Like different components on a single page could make a change to head, and one is expecting the stuff it added to head to remain, while the other is expecting stuff to be removed (like with a template approach, where it gets wiped and recreated). Thinking of competing elements making head changes seems tricky, potential for them to step on each other, especially with multiple devs or third-party component.
  • b
    Which approach do you recommend to follow within the HTML SPA page to manage error(s) returned if the Form validation failed at the server ? Example ?
  • t
    i believe you would return the form back but with additional markup that shows the error messages
  • m
    yes
  • m
    it's why I've avoided the topic for a long time 🙂
  • m
    it's easy if you are turbo-links, because you are just mimicing full page refreshes
  • m
    so sync is fine
  • m
    but htmx is finer-grained
  • m
    so it's not at all clear what the right thing to do is, and it introduces a state machine situation I'm not sure I'm a big fan of.
  • m
    Maybe we offer append as the standard, offer a way to re-execute scripts on every load and call it a day
  • m
    will think more about it
  • b
    This is a possibility at the condition that we can tell to htmx (there is an error, here is then the HTML to be added after let's say the last field of the form instead of showing the HTML list result)
  • t
    I think it just depends on the kind of UX you want… you can have it validate on blur and return individual fields maybe?
  • j
    Take a look at the way demo.htmx.org allows you to build using client-side templates and request interception. it isn't quite HTMX-only but is pretty close. works for client-only demos.
  • c
    would append affect those trying to reuse the templates with and without htmx? could there a merge option and use that as the default? (as in, only run the new markup compred to existing)
  • c
    if the head stuff goes into core instead of extension that would be a breaking change right? 2.0 if semver
  • a
    hello folks. is there a way to tell htmx to initially load data for a client-side-template using a GET request, but on a change update the api via a POST request?
  • l
    This is the key. You can use various 
    hx-swap
    and 
    hx-target
    client-side values, as well as the 
    HX-Swap
    , 
    HX-Target
    , and 
    HX-Retarget
    server-generated response headers to decide how you want to handle things. For example, if your default request targets the 
    body
    of a page, you can use 
    HX-Retarget
    to target the error message placeholder on the current page if an error arises. @boundless-leather-51644 You could also do validate-on-blur; it could be a bit chatty (lots of requests), but the payloads would be small and you'd get instant feedback. As with anything web-dev, there are lots of options, and the "right answer" is usually "it depends."
  • m
    yes, head stuff going into core (if it does) would be a 2.0 change
  • b
    Thanks. I will explore some of the bootstrap form validation base on your input: https://getbootstrap.com/docs/5.0/forms/validation/
  • l
    That's good - and, if you're sure your users will always have JavaScript available, that will work. If you want to make it work without JavaScript, though, you'll still need to handle the occasion when the form fails server-side validation. If you're learning, just put that in the back of your mind; get it working, then harden it. For that sort of thing, imagine someone using a browser that ignores formatting / max length / etc. rules that you have defined; picture them disabling JS and form validation, then submitting 8k of text in a first name field. (It sucks that this is the way a defensive web developer has to think - but that doesn't make those considerations any less important.)
  • b
    This is true but htmx is also a front-end JS technology and if JS is disabled the rendering will not work too (or badly). Finding a compromise between what should be part of the browser engine vs server side is certainly the most difficult thing that architects/developers have to deal with today vs old glory days of Struts, Apache Wicket, JSP, JSF. Remark: The nodejs - reactjs will fail too: https://www.spguides.com/form-validation-in-react-js/
1...870871872...1146Latest