What does the component here refer to? If you mean a web component, as long as the old element is not being replaced or deleted, the states associated to that element will be preserved.
And for the previous counter example, the actual DOM change should be just deleting the data-count attribute according to how morphdom works. So if it’s a custom element, the states stored inside it should just be fine.
Yeah, but interacting with the private attributes directly is a bit too hacky. So what I usually do is just execute JS Command from JavaScript.
Did some quick research to find out that Solid somewhat is different. Solid Context actually seems to work across different web components and it is indeed can be achieved due to how Solid Signal works. Here’s an example I found: https://playground.solidjs.com/anonymous/55d0ff7b-114d-45d2-a793-d9791f500bef . Good to know that!
@TunkShif your post is very relevant and I have been on this journey too. Svelte 5 is in preview and I expect that it will solve the shared state aspects of web components.
In terms of styling, I have not had any issues styling carbon, none. It uses sass based styles so I have been able to customise all of the theme tokens and override styles on component parts very easily and implement dynamic theme switching for light and dark mode.
I am not a fan of using Tailwind classes on elements as it leads to hard coding style in the code. It may be fine for one off web sites but I want a theme based approach for apps.
Tailwind also rubs against web standards and shadow DOM parts as there is no shadow DOM parts in your markup to hang utility tags on. Sure you can use @apply in CSS but then it’s easier to just write the CSS you want.
Tailwind is the current trend and will like all things fade into “bad idea, what drugs were we all on?” Perhaps in a year or two when the next Kool Kid like UnoCSS catches on.
I will say Shoelace is a non starter from accessibility point of view because it has always been in a state of “I don’t know, will try harder” by the maintainer when it comes to accessibility. Then the maintainer objects to including navigation components like a navbar! The UI shell is a critical concern of accessibility, so in the final analysis Shoelace is a non solution to basic application requirements. Adobe Spectrum V1 turns out to have a similar dilemma with no app shell navigation components. The hope here is for Spectrum 2 to deliver the goods.
That basically leaves Carbon as about the only viable accessibility focused web component library. Take a moment to read the depth of the concern just for the UI shell navigation. Check the Usage, Style and Accessibility sections on that page.
Some may think accessibility is nice to have. The reality is that it is table stakes for procurement in government systems and countries that have disability discrimination regulations. So without competent a11y, no one can purchase your software or solution, and yes they do have teams dedicated to evaluating conformance.
LiveSvelte does deal with this, but it’s not much of a “fight”, still it is a concern that needs due consideration.
However Chris McCord confirmed the segregation with Shadow DOM not needing phx-update="ignore" in this thread:
A component that doesn’t use the shadow DOM will get fouled up on liveview updates.
Of course there could be cases where the entire element is replaced due some parent/ancestor mutation, then sure you will lose the UI state, so its probably a good idea to ensure elements have unique IDs to minimise replacement. Live Elements does this here.
Given that custom elements and web components are W3C standards I think it is important to identify precisely where LiveView trips up and address these issues head on. I have no doubt I will hit some edge cases that may require some workarounds.
This is why I am conducting a series of experiments to understand the limitations and what the solutions are and the general feasibility. My view is that Phoenix must work ultimately well with web components to remain viable long term, so any hiccups or shortcomings will necessarily have to be addressed.
I do know from my own experiments that LiveSvelte has full reactivity with a very simple hook so that both client and server reactivity worked harmoniously together. There were some other issues I discovered with that solution, which is why I am not using it currently.
Once I have completed my experiments I will post some starter projects and guides for others to follow and clearly document any caveats, workarounds or show stoppers that I have identified.
So I finally came to the conclusion, that it is not feasible to use (most) webcomponents in LV right now. Its too hacky. If I find the time I’ll write my findings down.
But it is possible to write LV-aware WCs, so I had a look at Solid again and can confirm that sharing context across WCs also works directly in the browser, so no JSX needed.
Solid Context actually seems to work across different web components and it is indeed can be achieved due to how Solid Signal works. Here’s an example I found: https://playground.solidjs.com/anonymous/55d0ff7b-114d-45d2-a793-d9791f500bef . Good to know that!
