Render samples with shadowDOM to prevent style clashes.

[kaspth]

This renders our samples with shadowDOM on a custom element, so we can embed app styles in those elements and not have them leak into Showcase.

[kaspth]

Ok, it looks like if I rendered the element like this:

<showcase-isolated-context>
  <template data-shadowroot>
    <%= render "showcase/engine/stylesheets" %>
    <%= sample.preview %>
  </template>
</showcase-isolated-context>

The template element wouldn't, for some reason, be in the element's DOM to be able to be added to its shadowDOM. This does fit with the MDN documentation that I've been working off of, even though they don't explicitly tell you the template needs to be in the DOM before the element, all their examples do that.

Since we've already isolated the template tags in a container, we can use parentNode to find the element once we're connected. Not the prettiest, and it looks like all this could go away with declarative shadow DOMs (e.g. shadowroot="open" on the sample section even).

[kaspth]

@KonnorRogers thanks for the advice, I went with requestAnimationFrame instead of setTimeout, although I think they're roughly the same.

[kaspth]

Looks like shadowDOM also prevents us from logging any dispatched JavaScript events in the showcase-sample element, hm. Fun times!

[seanpdoyle]

Capybara will strip out all template element content from the moment it parses the HTML string. We might need to build a Nokogiri tree from response.body (for Integration Tests) or rendered (for View Test). From there, we'd traverse until the template and pass it's contents to Capybara.string so that we could make assertions on it directly.

[kaspth]

Gonna call this done for now, since it seems like ShadowDOM is tough for our use case of having user supplied HTML — and I'll have a hard time maintaining. We'll see how it goes with style clashes.