Rendering hyperscript-style responses

[pauleveritt]

First, kudos on the successor.

I realize this question is out-of-scope. You've clearly positioned htmlx as targeting/embracing HTML as the payload.

I'm toying with a static site generator that can save pages and fragments ashyperscript-style tuples. CSR updates then happen with a simple Preact VDOM diff style update.

I think this would require too big of a scope expansion for htmx:

• Intercept clicks and getting JSON, possibly storing as such in cache
• Allow overriding the DOM updates, to use something like Preact

Feel free to close this issue and say "we'll never allow that kind of pluggability."

[rschroll]

You'll want to check out the extension mechanism, currently in dev. You can view the docs here: https://dev.htmx.org/extensions/. Note that there's already an extension switch the DOM updates to morphdom (https://dev.htmx.org/official-extensions/#morphdom-swap). I would naively assume that preact could be used similarly.

For intercepting requests, you can add a listener to the beforeRequest event (https://dev.htmx.org/events/#beforeRequest.htmx), which could block requests where the answer is cached. I don't know if it's possible to insert that cached value as if it was the response, though.

[pauleveritt]

Thanks for the fast response. The second part is "way down the road". The first part, I suspect can go a long way scratching my itch with HTML fragments, so I will try the morphdom and learn about htmx.

[1cg]

Hi Paul,

You are right that this is out of scope, but @rschroll is also right that this is exactly what the extension mechanism is intended to address. The morphdom extension mentioned shows how to implement a custom swap strategy:

https://github.com/bigskysoftware/htmx/blob/dev/src/ext/morphdom-swap.js

And the client-side-templating extension shows how to catch a JSON request and render it as HTML before htmx starts processing the content:

https://github.com/bigskysoftware/htmx/blob/dev/src/ext/client-side-templates.js

If you get into it and there isn't the right cut-point in the request life cycle to implement what you want we can take a look at the use case and determine if a new cut point makes sense.

Thanks for taking a look at htmx!