Let's make shoelace work with liveview

This is great. Let’s see if we can fix these.

When we were testing it out we found that adding an ID to some of the Shoelace slots helped with patching. It triggers different behavior in morphdom since the id is the nodeKey so rather than patching as children it patches directly.

There’s a more drastic option as well…

// WARNING: Lazy example. There's probably much more to it.
onBeforeElUpdated: (from, to) => {
  // Effectively make sure Shoelace always wins the attr merge by assigning from
  // back over it.
  // 
  // This could be done better with a "Managed Attr" list where instead of this
  // all or nothing approach below one could say: 
  // "Ok, for attr ABC of element XYZ we never patch it."
  // or even handle some specifically...
  // "For class of element XYZ we can merge the classes, but never remove"
  //
  // BUT I expect this would result in unnecessary renders all the time?
  //
  // This is why I think there are ultimately low-level changes involved if we want
  // to support arbitrary WCs
  //
  if (from.tagName.startsWith("SL-")) {
    [...to.attributes, ...from.attributes].forEach((attr) => {
      to.setAttribute(attr.name, attr.value); 
    });
},

@Sebb if you have a repo where you’re testing stuff I’m happy to help out. I’m benkimpel on github.

Wow that’s brutal.
And as far as I understand the problem now, this is the only way (without too much special-case-handling)

I don’t see how LV could ever handle arbitrary WC-libraries that do not follow at least these rules:

• Do not generate elements in the light-DOM
• Do not change the value of attributes that are not in a special namespace (and could thus be easily protected from LV)

I made the repo public.

Here’s the relevant issue in shoelace’s repo. Unfortunately I don’t think this is something that’s going to get addressed

That’s easily fixed by the onBeforeElUpdated callback which sets the defaults if not set.

I would’ve thought you’d need a phx-update="ignore“ on the shoelace components that use the light dom/change attributes. What’s the outcome when you use it?

Sure I could do that and it would be OK for several components.
But what about those that take children?
This would get messy quickly.

Yeah. That’s kind of what i was trying to get at with my element adapter proposal. With WCs that can do anything there has to be some translation layer between what lv is trying to do and how a WC can perform or ignore that operation and we can’t expect the WC author to do so. It’s most obvious in forms right now due to all of the element hardcoding. Aria, light dom mods, and simpler things could be handled in onBeforeElUpdated. It wouldn’t be pretty but it could work.

And sure, we could ignore updates but then the markup rendered from phoenix and passed into a WC is basically static (from phx side) and we have a new set of problems.

This is a tough one and it might just be that lv will only work with very simple WCs.

(I hadnt tested breadcrumbs, btw. Glad you tried that one.)

For example, this fixes the button group…

// onBeforeElUpdated

// Protect sl- classes
if (from.tagName.startsWith("SL-")) {
  from.classList.forEach((cls) => {
    if (cls.startsWith("sl-")) {
      to.classList.add(cls);
    }
  });
}

But how fragile is all of this? idk