-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rendering hyperscript-style responses #40
Comments
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. |
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 |
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! |
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 as
hyperscript
-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
:Feel free to close this issue and say "we'll never allow that kind of pluggability."
The text was updated successfully, but these errors were encountered: