Use htmx where useful #4431
bschmalhofer
started this conversation in
Ideas
Replies: 1 comment 2 replies
|
Not sure if you guys are already aware of it, but you can avoid conflicts in some parts of the application by using the hx-boost attribute. For example, if you want htmx to be executed only on some parts of the page, you can add hx-boost="false" to the body element, and then add hx-boost="true" on DIVs, forms or any other elements that you want htmx to be looking at. The opposite also might be valid: you can have hx-boost="true" at the body element, and disable it on some specific parts of the application with hx-boost="false" |
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
https://htmx.org/ might lead to more flexibility and less obtuse code. For new features and complete refactorings things look very simple. An example is provided in https://github.com/RotherOSS/otobo/tree/htmx_dancer2_showcase_rebased_ 1
Another example is peridoc reloading of a Dashboard component::
The question whether htmx works together with the existing JavaScript is important. I see two clashes. htmx does something and previous fuctionality is lost. Or the existing JavaScript does something and htmx is perplexed. Both cases can be handled reasonably well. htmx supports callbacks, like `hx-on::after-settle, which can be used to replicate the current behavior.
When Core methods reload content with hx tags then
htmx.process(Swappedelem)must be called. See also the htmx_experiment in the non-public ticketicalintegration repository.Cheap trick:
$SwappedElem[0]turns a jquery element into a plain JavaScript element.All reactions