4 ms·

Quick question, as it made me curious. Can I send the content that I want to swap to the server itself? Say I want to submit a form to the backend, will it only

by mhitza 4y ago

Quick question, as it made me curious. Can I send the content that I want to swap to the server itself? Say I want to submit a form to the backend, will it only send form fields or is there a way to send the form html itself?

recursivedoubts 4y ago
that would probably be best accomplished w/ a custom htmx:configRequest handler: https://htmx.org/events/#htmx:configRequest https://htmx.org/events/#htmx:configRequest you could jam the outerHTML of the detail.target into the detail.parameters map, maybe based on the presence of an attribute...
- mhitza 4y ago
  I'm gonna make a note on that when I have cycles to burn to experiment with htmx. From my understanding of reading that section, parameters being a container of kv pairs, I'd have to hack on the internals of htmx for it to be able to send a pure string (not form/multipart) as the body of a post/put request. If I get around of experimenting with that, and it fits my flow, would that be something you'd accept back into the project as a contribution to the code?
  - recursivedoubts 4y ago
    i don't think you'd need to hack the internals, you just hook into that event to do what you need: htmx.on("htmx:configRequest", function(evt) { evt.detail.parameters['my-html'] = evt.target.outerHTML; // or whatever } you can jump on the discord and we can help you out when the time comes: https://htmx.org/discord https://htmx.org/discord
artificialLimbs 4y ago
Why would you do that? Curious about use case.
- mhitza 4y ago
  I have a nifty (or so I'd like to think) slapped together HTML parser, that instead of building a DOM tree, streams the HTML nodes as a list. Which in practice makes it easier to validate a field, and insert the appropriate validation message at the right location, without switching from request -> data representation -> validation failure model -> templating language ifdefs to inline the validation classes and additional helper text. Might sound not that convenient for basic things like login forms, but I have frontend code that builds dynamic form fields, which I'd like to not replicate via the backend templating language, if extracting data from HTML itself is a breeze in my case. Of course I'm going to do that myself anyway, but I'd rather use an established library which also handles in browser page restoration/caching (possibly also fragments), instead of rolling my own JS lib.

by mhitza 4y ago

recursivedoubts 4y ago

that would probably be best accomplished w/ a custom htmx:configRequest handler: https://htmx.org/events/#htmx:configRequest https://htmx.org/events/#htmx:configRequest you could jam the outerHTML of the detail.target into the detail.parameters map, maybe based on the presence of an attribute...

mhitza 4y ago
I'm gonna make a note on that when I have cycles to burn to experiment with htmx. From my understanding of reading that section, parameters being a container of kv pairs, I'd have to hack on the internals of htmx for it to be able to send a pure string (not form/multipart) as the body of a post/put request. If I get around of experimenting with that, and it fits my flow, would that be something you'd accept back into the project as a contribution to the code?
- recursivedoubts 4y ago
  i don't think you'd need to hack the internals, you just hook into that event to do what you need: htmx.on("htmx:configRequest", function(evt) { evt.detail.parameters['my-html'] = evt.target.outerHTML; // or whatever } you can jump on the discord and we can help you out when the time comes: https://htmx.org/discord https://htmx.org/discord

artificialLimbs 4y ago

Why would you do that? Curious about use case.

mhitza 4y ago
I have a nifty (or so I'd like to think) slapped together HTML parser, that instead of building a DOM tree, streams the HTML nodes as a list. Which in practice makes it easier to validate a field, and insert the appropriate validation message at the right location, without switching from request -> data representation -> validation failure model -> templating language ifdefs to inline the validation classes and additional helper text. Might sound not that convenient for basic things like login forms, but I have frontend code that builds dynamic form fields, which I'd like to not replicate via the backend templating language, if extracting data from HTML itself is a breeze in my case. Of course I'm going to do that myself anyway, but I'd rather use an established library which also handles in browser page restoration/caching (possibly also fragments), instead of rolling my own JS lib.