26 ms·

I really want to try htmx but it specifically prohibits my most common usecases: 1) I want to take a JSON response, create HTML from it, and replace the target

by cpburns2009 3mo ago

I really want to try htmx but it specifically prohibits my most common usecases: 1) I want to take a JSON response, create HTML from it, and replace the target element with the generated HTML. 2) Similar to the above, take a JSON response, perform some action, and do nothing to the source element. Is there a plugin to add this? I want to move away from jQuery, and having a small framework to wire up hooks would be useful.

igor47 3mo ago
Why are you so wedded to JSON responses? HTMX is meant to be used to render html; my big HTMX app basically never(1) renders JSON, so much so that I have a standing instruction to coding agents that if they're rendering JSON they're probably doing something wrong. If you're attached to JSON because you're working with external API s you don't control, a good place to perform those kinds of actions is in your backend, which can then return html to your frontend (1) the exception is I think in one place concerned a flow for uploading images, where client side requests a signed url, uploads to that url, then registers completion. Getting the signed url back is JSON meant for the uploader
- wasting_time 3mo ago
  I made a UI with htmx, it works great. But now I want to add a JSON API to the program: I could reuse the same routes (/create, etc), but require an application+json header; or add a full /api/ component essentially duplicating the logic from the main app. Neither option is great.
  - igor47 3mo ago
    I do get kind of annoyed that htmx submits forms using form url encoding. It's non trivial to validate, see https://igor.moomers.org/posts/zod-schemas-htmx https://igor.moomers.org/posts/zod-schemas-htmx As a result for POST requests you have to have htmx routes that accept urlencode and API routes that accept JSON, and JSON is far superior. But for outputs I actually think separating your UI and API is helpful. The code reuse is not worth the entanglement of concerns.
  - Aeolos 3mo ago
    Fat services, thin routes. Try moving your business logic to a library and consume it from both your UI and API routes. That minimizes duplication and decouples your public API resolvers (with backwards compatibility requirements etc) from your private UI resolvers (which you want to evolve rapidly to optimize your UIX). That's what we did and it works pretty well in practice.
  - yawaramin 3mo ago
    Ok, for the sake of completeness–why do you want to add a JSON API to the program? Quite a lot depends on the reason.
    - wasting_time 3mo ago
      It's a service, and I want to add a CLI for humans and agents. Aeolos' reply makes a lot of sense, I can refactor the backend into a library and add thin UI and API routes on top of it.
- gofreddygo 3mo ago
  Why are you so wedded to JSON responses? I'd assume because of the conception that json = data. Html = presentation. But if you just use barebones html, this could work very well. Just add a wrapper in the api to return json as html to try it out a bit.
- cpburns2009 3mo ago
  I want to handle a JSON response because I usually return data for multiple page elements. These aren't external APIs, they're requests to the backend server. A simple example is adding a note to a product or order. When you submit it, it gets inlined, and say a visual note counter is incremented. Usually I'll return multiple HTML fragments if it's convenient, but I'll return a data structure if needed.
  - Doxin 3mo ago
    You can return data for multiple page elements with HTMX too using the "OOB" mechanism.
masfoobar 3mo ago
Sounds like you are going through similar struggles as a few backend developers I had trying out htmx. Years of muscle memory with returning JSON and letting the frontend (javascript/jquery) to handle the html. They were making a big deal with this change. In the end the change is rather minimal. The outcome is reduced javascript code and more server side html templates. Pretty much most of the code is now handled on the server side. Just organise the html templates! Pseudo example Instead of :- <code> // returning as Json [Get] Response GetUser(int id) { var user = getUser(id); return ToJson(user); } </code> You are just doing :- <code> // returning as HTML [Get] Response GetUser(int id) { var user = getUser(id); return View("som-user-template", user); } </code> I don't know what 'hooks' you need, but whatever they are doing you can move them over to returning/updating section of html on the screen with htmx.
- cpburns2009 3mo ago
  By wiring up hooks I just mean binding a callback to a button that calls fetch() and processing the response (usually replacing HTML, but may modify content and classes on other elements). Basically what I'm looking for is being able to specify a callback (ideally just a global name set from HTML) that will be called with a response object when JSON is returned. I prefer most coding to happen server side, but sometimes client side JS is needed.
  - masfoobar 3mo ago
    But you can do this with htmx by using the respected hx-* attributes. For example, on button click to GET html. Again, you can specify what you want to do with the returned html with attributes such as hx-swap Unless I am misunderstanding, of course. I do remember triggers/hooks with things like Angular and Knockout. I don't miss this method of web development. I recommend starting small and working up with htmx. Their examples section on the official website is pretty good.

igor47 3mo ago

Why are you so wedded to JSON responses? HTMX is meant to be used to render html; my big HTMX app basically never(1) renders JSON, so much so that I have a standing instruction to coding agents that if they're rendering JSON they're probably doing something wrong. If you're attached to JSON because you're working with external API s you don't control, a good place to perform those kinds of actions is in your backend, which can then return html to your frontend (1) the exception is I think in one place concerned a flow for uploading images, where client side requests a signed url, uploads to that url, then registers completion. Getting the signed url back is JSON meant for the uploader

wasting_time 3mo ago
I made a UI with htmx, it works great. But now I want to add a JSON API to the program: I could reuse the same routes (/create, etc), but require an application+json header; or add a full /api/ component essentially duplicating the logic from the main app. Neither option is great.
- igor47 3mo ago
  I do get kind of annoyed that htmx submits forms using form url encoding. It's non trivial to validate, see https://igor.moomers.org/posts/zod-schemas-htmx https://igor.moomers.org/posts/zod-schemas-htmx As a result for POST requests you have to have htmx routes that accept urlencode and API routes that accept JSON, and JSON is far superior. But for outputs I actually think separating your UI and API is helpful. The code reuse is not worth the entanglement of concerns.
- Aeolos 3mo ago
  Fat services, thin routes. Try moving your business logic to a library and consume it from both your UI and API routes. That minimizes duplication and decouples your public API resolvers (with backwards compatibility requirements etc) from your private UI resolvers (which you want to evolve rapidly to optimize your UIX). That's what we did and it works pretty well in practice.
- yawaramin 3mo ago
  Ok, for the sake of completeness–why do you want to add a JSON API to the program? Quite a lot depends on the reason.
  - wasting_time 3mo ago
    It's a service, and I want to add a CLI for humans and agents. Aeolos' reply makes a lot of sense, I can refactor the backend into a library and add thin UI and API routes on top of it.
gofreddygo 3mo ago
Why are you so wedded to JSON responses? I'd assume because of the conception that json = data. Html = presentation. But if you just use barebones html, this could work very well. Just add a wrapper in the api to return json as html to try it out a bit.
cpburns2009 3mo ago
I want to handle a JSON response because I usually return data for multiple page elements. These aren't external APIs, they're requests to the backend server. A simple example is adding a note to a product or order. When you submit it, it gets inlined, and say a visual note counter is incremented. Usually I'll return multiple HTML fragments if it's convenient, but I'll return a data structure if needed.
- Doxin 3mo ago
  You can return data for multiple page elements with HTMX too using the "OOB" mechanism.

masfoobar 3mo ago

Sounds like you are going through similar struggles as a few backend developers I had trying out htmx. Years of muscle memory with returning JSON and letting the frontend (javascript/jquery) to handle the html. They were making a big deal with this change. In the end the change is rather minimal. The outcome is reduced javascript code and more server side html templates. Pretty much most of the code is now handled on the server side. Just organise the html templates! Pseudo example Instead of :- <code> // returning as Json [Get] Response GetUser(int id) { var user = getUser(id); return ToJson(user); } </code> You are just doing :- <code> // returning as HTML [Get] Response GetUser(int id) { var user = getUser(id); return View("som-user-template", user); } </code> I don't know what 'hooks' you need, but whatever they are doing you can move them over to returning/updating section of html on the screen with htmx.

cpburns2009 3mo ago
By wiring up hooks I just mean binding a callback to a button that calls fetch() and processing the response (usually replacing HTML, but may modify content and classes on other elements). Basically what I'm looking for is being able to specify a callback (ideally just a global name set from HTML) that will be called with a response object when JSON is returned. I prefer most coding to happen server side, but sometimes client side JS is needed.
- masfoobar 3mo ago
  But you can do this with htmx by using the respected hx-* attributes. For example, on button click to GET html. Again, you can specify what you want to do with the returned html with attributes such as hx-swap Unless I am misunderstanding, of course. I do remember triggers/hooks with things like Angular and Knockout. I don't miss this method of web development. I recommend starting small and working up with htmx. Their examples section on the official website is pretty good.