baseplate-admin
commented
8 months ago After some digging this is due to
<button>
<div> Hello world</div>
</button>Open baseplate-admin opened 8 months ago
baseplate-admin
commented
8 months ago After some digging this is due to
<button>
<div> Hello world</div>
</button>
patricknelson
commented
8 months ago Sorry @baseplate-admin but this is an utterly massive and apparently complicated wall of text.
Can you do me a favor and simplify this for me please and instead of screenshots of tons of code, can you reduce this down to it’s simplest form in a small/simple repo where I can reproduce please? Sadly I don’t have time to dissect this just to figure out if it’s really an issue with svelte-retag.
patricknelson
commented
8 months ago p.s. Here’s what I strongly recommend you do:
I always find that the more you can simplify/reduce the issue to its simplest components the easier it is to reason about and eventually solve (and importantly: communicate). Thanks!
baseplate-admin
commented
8 months ago Yep thought so, my university opened so i have less time than before, please dont close this issue and i will see how to provide a stackblitz example
patricknelson
commented
8 months ago No, please put in a repo that I can clone down and reproduce locally, especially since this one seems complicated. I prefer that over an online demo because I need to quickly reproduce it locally. It'll also to help you narrow it down to only the bare minimum required parts (and helps to weed out false alarms).
Just to address this:
Yep thought so
Ok... well just look at it from my perspective: I'm not a python dev and I'm obviously not familiar with your codebase. Since you probably thought this might be hard, that's a clue that this work needs to be done. Plus, to ensure folks help me help them as quickly as possible, I even outline this in the bug issue template (inspired by the main Svelte repo), i.e.
Describe the bug: A clear and concise description of what the bug is. Reproduction: Please provide a link to a repo or REPL that can reproduce the problem you ran into.
Just some advice. Not sure you needed it or anything but figured I'd put that out there for you. Again: Simpler is better and, since this is potentially complicated, a local repro is going to be important to help me understand it more deeply.
baseplate-admin
commented
8 months ago Got it. I will put codes in a git repo
patricknelson
commented
8 months ago Hey @baseplate-admin it's been a few weeks. Have you had a chance to work on or think about a more distilled proof of concept for this bug/issue that you're seeing?
baseplate-admin
commented
8 months ago Hi, i am extremely sorry. University started and i am much busy with studies.
I would love to help you with this but i fear i wont be able to until next month
patricknelson
commented
8 months ago K no worries; I'm swamped as well by the very project that spawned the creation of svelte-retag itself (the redesign of our homepage). 😅 No rush though; will just keep an eye on this for now.
spuky
commented
6 months ago @baseplate-admin wow what a wild mixture of svelte and htmx (you are begging for trouble)
i'd guess htmx is trying to add its saved state (the dom before you navigated away..) to the dom before the output of your custom element is even in the dom... so it does not find the location where to put the cached stuf...
and just adds it to the Bottom of the Page..
it is really not the best idea to try to mess with the Dom of the custom element... which htmx would be doing in that case...but is not able because it runs before your custom element...
that is my analysis by looking over your code and the vids for a little while...
htmx is made for static html and a custom element is not static html...
I'd not consider this as a bug in svelte-retag or svelte nore in htmx... you are trying to combine stuff that do not go together...
Edit looked a little close it is the otherway arround... htmx is putting the renderd dom in place an then your custom element is messing up at some point...
baseplate-admin
commented
6 months ago wow what a wild mixture of svelte and htmx
XD you are right, its a never seen before concoction.
i'd guess htmx is trying to add its saved state (the dom before you navigated away..) to the dom before the output of your custom element is even in the dom... so it does not find the location where to put the cached stuf...
Yes you are right on this (partially), all the API used by htmx are internal, so we have almost no way to modify this default behavior.
htmx is made for static html and a custom element is not static html...
I disagree on this. Because web-components are html in nature.
I'd not consider this as a bug in svelte-retag or svelte nore in htmx... you are trying to combine stuff that do not go together...
I think it's a bug with svelte-retag. Specially how it implementes the svelte-retag wrapper. I think if that goes away, then this bug wont exist..
Edit looked a little close it is the otherway arround... htmx is putting the renderd dom in place an then your custom element is messing up at some point...
Yep you are on the right path. The rendered html is not being correctly processed by svelte-retag.
All in all i worked around this issue by not doing
<button> <div></div> </button>I am sorry if i sound a bit rude. I am just a bit burned out today.
patricknelson
commented
6 months ago Have you tried <button><span></span></button>? Shot in the dark as I have zero comprehension of what's happening here (partly due to saving brain CPU cycles processing this; trying not to get nerd sniped! 😅). Only say that since you narrowed it down to that and <div> inside buttons isn't technically semantically correct; usually that's easily fixed with CSS but maybe there's something non-CSS specific happening there.
@baseplate-admin you said:
I think it's a bug with
svelte-retag. Specially how it implementes thesvelte-retagwrapper. I think if that goes away, then this bug wont exist..
Can you break down high level why you think this? Just the broad strokes; what's your theory? Does this happen to custom elements (web components) which are being appended to the DOM asynchronously after page load? Is this affecting svelte-retag managed custom elements which are nested inside of other custom elements, or maybe more importantly, is there anything inside of a svelte-retag custom element which is being separately changed by an external library (like htmx)?
Also, to top all that off: Have you considered using shadow DOM instead? Maybe give that a shot as well and see how that works, since that should help encapsulate things a bit better.
htmx is made for static html and a custom element is not static html...
I disagree on this. Because
web-componentsare html in nature.
While custom elements are "HTML in nature" (after all, they descend from HTMLElement), they function differently from native HTML elements because they are much more likely to mutate light DOM content; it's entirely up to the programmer what those elements do. That's why the shadow DOM API exists (particularly the closed shadow DOM); so you can encapsulate your code away from the outside light DOM and also protect it from accidental conflicts or modifications, etc.
That's why I think @spuky might be onto something here. My gut instinct is that if htmx is swapping content above a svelte-retag managed element (like <coreproject-page-explore>) then I'd expect it to work fine; this is because svelte-retag is concerned about it's own contents. It manages the component and it's slot on connectedCallback() and disconnectedCallback(). However, if htmx is modifying the contents anywhere inside of the svelte-retag custom element, all bets are off; who knows what could happen (now you're in both svelte-retag and Svelte land with Svelte's and your custom element's code).
patricknelson
commented
6 months ago p.s. On that "HTML in nature" point, take the <details> tag for example. Think of it as a custom element as well that utilizes a shadow DOM. You plug your HTML into the light DOM, which is completely partitioned from the shadow DOM (and totally free for htmx to mutate as it sees fit) and the <details> element is able to utilize slots to input default content (i.e. the details) and also the <summary> tag which, for all intents and purposes, is like a summary slot.
It's not obvious looking at the light DOM here (which is all we can see) how the <details> element is able to actually hide the default slot content at all. The only hint we have is an implementation-specific to the <details> element itself, which is that it is missing the open attribute.
That's why I think if you tucked this into the shadow DOM, the results might be more aligned with what you expect. And if you cannot use the shadow DOM because you need content accessible to htmx, well... maybe therein lies the problem?
Edit: p.s. I could be wrong about the implementation details of <details> itself per se, I'm just using it as a metaphor (so sorry about the confusion there in case I'm wrong about precisely how it's implemented under the hood). The core point is still about encapsulation and separation of concerns. 😄
baseplate-admin
commented
5 months ago is there anything inside of a svelte-retag custom element which is being separately changed by an external library (like htmx)?
I think this is mostly the correct analogy, htmx swaps the html code and it executes any JavaScript that is within it. So basically what is happening is :
<svelte-retag>
<svelte-retag></svelte-retag>
</svelte-retag>I think this is un-fixable before addressing
Yep you remind me of this issue, This was also causing an issue with layouts with htmx,
@tokitouq you mentioned this issue, remember?
patricknelson
commented
5 months ago Hey @baseplate-admin. That’s just a side effect. Do you have any details on root cause?
Also, the core of my point is that this library doesn’t officially support outside libraries (i.e. those that are not part of the Svelte component, that is) modifying the contents of stuff inside of the custom element. It’s managed top down. That is, if HTMX is involved, fine, but as long as it’s not then reaching into the element. Adding elements that are svelte-retag elements might be ok (cannot guarantee it’ll work).
Anyway, until you have details on a simple way to reproduce this bug so we can get into the root cause, then I’m not sure if there’s anything I can do here (myself). Obviously, PR’s are also welcome (but would come with the same quality standard, i.e. a root cause analysis with the proposed solution).
Describe the bug
Hi, so when i navigate from one page to another, there is a severe bug that causes elements to mount in a different place from where it needs to be, ( code source )
screen-recorder-sat-dec-23-2023-10-40-07.webm screen-recorder-sat-dec-23-2023-10-47-53.webm
So here's the function behind button clicks
Which in turn invokes ( refer to source )
Localstorage state :
Reproduction
Reproduction of this issue is a bit hard. Since running the project is not as simple ( i don't recommend running this at all )
git clone https://github.com/baseplate-admin/coreproject.gitcd backendnpm ipipx install poetrypipx ensurepathpoetry run poe devnpm run devhttp://127.0.0.1:9000/animeI will try to recreate this in stackblitz
Logs
No response
System Info
Severity
annoyance