5 ms·

I used it on a project and I liked it but then I got into situations where I needed to pass a bunch of data back to the rendering page and it got really messy.

I used it on a project and I liked it but then I got into situations where I needed to pass a bunch of data back to the rendering page and it got really messy. The author says on the HTMX page that if you have this type of situation then HTMX is probably not the greatest fit. Also as the project got larger there was a lot of issues with like "Wait, why isn't this loading? Oh man someone changed the name of a div I was using". It's just not as clear when things stop working compared to most JS frameworks (which I hate, hence my interesting in HTMX). I think for smaller projects it can be decent though.

arcanemachiner 3y ago
I think it would be a good idea in these situations (many cooks in the kitchen) to use a data attribute for each HTML element that uses HTMX, such as `data-htmx-id` to reference your elements instead of just using the `id` attribute (which already carries a lot of contextual baggage). This would solve a couple potential issues: - Identifying that the element is used for HTMX swaps - Warning anyone that changing this attribute will break said HTMX swap
- DoesntMatter22 3y ago
  Sure, there are ways to work around it but it's just fairly brittle in that way, those measures help but on a large project people are going to be breaking things relatively frequently.
  - deleted 3y ago
    [deleted]
mostlysimilar 3y ago
> I got into situations where I needed to pass a bunch of data back to the rendering page and it got really messy. Could you not fetch that data separately from the patterns htmx provides and do some light parsing/rendering logic client-side?
- DoesntMatter22 3y ago
  That data needs to go to the page itself. Like you need to pull data that is on the main page and send that data down to the modal form submission. That is tricky. Is it doable? Yeah, it can be done but it's really ugly at that point.
  - a_subsystem 3y ago
    The data was on the server at some point to begin with. How could it be tricky to put it somewhere just because $component is a modal?
    - DoesntMatter22 3y ago
      How could it be tricky to have html loaded on multiple different parts of the page? Do you think it happens automatically? You have to track all of it. It's a pain. You need to embed hidden inputs then need to capture them, send them off, The modal stays on the screen but the underlying page needs to change behind it. If you think that's easy then you'll love HTMX
      - a_subsystem 3y ago
        You mean something like this? This does get a bit messier... https://htmx.org/docs/#oob_swaps https://htmx.org/docs/#oob_swaps
  - throwaway2990 3y ago
    What you’re explaining didn’t make much sense. Would like to see an example where it’s messy because I haven’t seen one yet. The ids changing is annoying tho!
ecshafer 3y ago
It sounds like in a bigger project a simple linter which checks that front end htmx and backend htmx tags have a match would solve that issue.
- DoesntMatter22 3y ago
  That would help, and certainly there are ways around it, but in the state of things right now it's gets ugly.
ExGustoCustomer 3y ago
I've found Alpine + HTMX a good combination for similar use cases, though I haven't tried to use them both with the same page elements and large collections of data. In my case Alpine localizes date times client side [1] and I intend to use Alpine to pass a bunch of data back to the rendering page. When you say HTMX got real messy, did you find something like Alpine conflicting with HTMX on the same elements? [1]: https://pentacent.com/blog/date-time-inputs-with-alpine-js/ https://pentacent.com/blog/date-time-inputs-with-alpine-js/

arcanemachiner 3y ago

I think it would be a good idea in these situations (many cooks in the kitchen) to use a data attribute for each HTML element that uses HTMX, such as `data-htmx-id` to reference your elements instead of just using the `id` attribute (which already carries a lot of contextual baggage). This would solve a couple potential issues: - Identifying that the element is used for HTMX swaps - Warning anyone that changing this attribute will break said HTMX swap

DoesntMatter22 3y ago
Sure, there are ways to work around it but it's just fairly brittle in that way, those measures help but on a large project people are going to be breaking things relatively frequently.
- deleted 3y ago
  [deleted]

mostlysimilar 3y ago

> I got into situations where I needed to pass a bunch of data back to the rendering page and it got really messy. Could you not fetch that data separately from the patterns htmx provides and do some light parsing/rendering logic client-side?

DoesntMatter22 3y ago
That data needs to go to the page itself. Like you need to pull data that is on the main page and send that data down to the modal form submission. That is tricky. Is it doable? Yeah, it can be done but it's really ugly at that point.
- a_subsystem 3y ago
  The data was on the server at some point to begin with. How could it be tricky to put it somewhere just because $component is a modal?
  - DoesntMatter22 3y ago
    How could it be tricky to have html loaded on multiple different parts of the page? Do you think it happens automatically? You have to track all of it. It's a pain. You need to embed hidden inputs then need to capture them, send them off, The modal stays on the screen but the underlying page needs to change behind it. If you think that's easy then you'll love HTMX
    - a_subsystem 3y ago
      You mean something like this? This does get a bit messier... https://htmx.org/docs/#oob_swaps https://htmx.org/docs/#oob_swaps
- throwaway2990 3y ago
  What you’re explaining didn’t make much sense. Would like to see an example where it’s messy because I haven’t seen one yet. The ids changing is annoying tho!

ecshafer 3y ago

It sounds like in a bigger project a simple linter which checks that front end htmx and backend htmx tags have a match would solve that issue.

DoesntMatter22 3y ago
That would help, and certainly there are ways around it, but in the state of things right now it's gets ugly.

ExGustoCustomer 3y ago

I've found Alpine + HTMX a good combination for similar use cases, though I haven't tried to use them both with the same page elements and large collections of data. In my case Alpine localizes date times client side [1] and I intend to use Alpine to pass a bunch of data back to the rendering page. When you say HTMX got real messy, did you find something like Alpine conflicting with HTMX on the same elements? [1]: https://pentacent.com/blog/date-time-inputs-with-alpine-js/ https://pentacent.com/blog/date-time-inputs-with-alpine-js/