Replies: 8 comments 13 replies
-
|
I am thinking that the swapping mechanism htmx uses is the default one, and potentially I need to figure out how to use alpine.morph through https://htmx.org/extensions/alpine-morph/ |
Beta Was this translation helpful? Give feedback.
-
|
@gone did you have any success with this problem? Having similar issue but no luck so far in finding the solution. |
Beta Was this translation helpful? Give feedback.
-
|
no - I turned off the back cache |
Beta Was this translation helpful? Give feedback.
-
How did you disabled the HTMX cache? Changing the source code? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Have you seen this one?: https://dev.htmx.org/extensions/alpine-morph/ |
Beta Was this translation helpful? Give feedback.
-
|
If Alpine-morph extension can't solve it, this is more of an HTMX issue. HTMX maintainers like Alpine, and want it to be compatible. Alpine can't really do anything about it. |
Beta Was this translation helpful? Give feedback.
-
|
Why is it an htmx issue? It isn't doing anything fancy beyond swapping out <body>'s innerHTML with a snapshot. I could see other libraries doing similar things. Alpine's <template x-for> logic could handle this without knowing about htmx. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @hudon. We need an API from alpine to serialize the existing state and restore it on demand. This could be a separate extension rather than being supported on the Alpine core. So that other libs needing this behavior can write an extension to support this particular use case. |
Beta Was this translation helpful? Give feedback.
-
|
I think I found the root cause of the problem. The template child elements are being saved to the cache, and when being restored from the cache, alpine loses the reference of the template's child element, thus considering them as a different element. I found a temporary workaround which is adding "x-from-template" attribute to the template's children. and once the HTMX restores the document, I just select and remove the elements which contain that attribute. Example: <template x-for="element in list">
<li x-text="element.label" x-from-template></li>
</template>After alpine processes the document, it turns into: <template x-for="element in list">...</template>
<li x-text="element.label" x-from-template></li>
<li x-text="element.label" x-from-template></li>
<li x-text="element.label" x-from-template></li>
...But when this document is being stored to cache by htmx and when restored, alpine loses To fix this issue, we can remove those <script>
document.addEventListener('htmx:historyRestore', (evt) => {
document.querySelectorAll('[x-from-template]').forEach((e) => e.remove())
})
</script>This will remove the orphaned template children and thus prevent errors. Of course, this is a temporary workaround, I would like to know if we have a way from the alpine library to clean up template tags on demand or just re-attach them to the template reference. If we have any way to clean up template tags, we can create a htmx plugin to run the clean-up function every time the page is stored in to cache. |
Beta Was this translation helpful? Give feedback.
-
|
This was exactly what I needed -thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much! Been pulling my hair out! |
Beta Was this translation helpful? Give feedback.
-
|
exactly what i needed... also worked with x-if. thanks man. <3 |
Beta Was this translation helpful? Give feedback.
-
|
You can also use |
Beta Was this translation helpful? Give feedback.
-
|
this worked for me thank you |
Beta Was this translation helpful? Give feedback.
-
|
For reference for the discussion, here are the htmx docs on the feature: |
Beta Was this translation helpful? Give feedback.
-
|
Possible solution that might be closer to the htmx way by preventing the content inside the template from being stored in htmx's history cache local storage object. This also allows the history cache to still work for other elements. Use Example usage for x-for: <template x-for="element in list">
<li x-text="element.label" hx-history="false"></li>
</template>Example usage for x-if: <template x-if="true">
<li hx-history="false">Hello World</li>
</template> |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
The issue basically stems from HTMX just saving the document state as html, which alpine has no way to know that the element nearby is actually the contents of the template tag when the new template is evaluated |
Beta Was this translation helpful? Give feedback.
-
|
Actually, this seems happen in livewire v3 too when using |
Beta Was this translation helpful? Give feedback.
-
|
fixed! #4015 |
Beta Was this translation helpful? Give feedback.
-
I think this is potentially a feature request and not a bug:
I have a sample app (https://github.com/rwwiv/min_test_alpine_htmx) that has a page that uses a template tag and x-for to do a little bit of dynamic rendering. If you open that page (either page2 or page3 in the app), move to another page and then hit back you will get errors in the console, and duplicate html.
I am pretty sure what is happening is that when the back event occurs, htmx is restoring a cached html state (https://htmx.org/docs/#history) which includes the prior alpine state, and also the template tag and alpine directives that created the state. The alpine directives re-run, and the old state is preserved but is no longer managed by alpine.
Is there some way we can serialize the current state such that when we restore the cache alpine knows to pick that up rather than starting fresh? Especially if that includes data and not just html tags.
Beta Was this translation helpful? Give feedback.
All reactions