resolve multiple <slot> elements rendering on the home page

[thescientist13]

Related Issue

resolves #433

Summary of Changes

Did some experimentation and comparisons between HTMLElement and LitElement (you can compare in the home page index.html right now).

From my research I learned / observed a couple interesting insights into Shadow DOM / <slot>

1. <slot>s should be named

2. They only seem to support a shallow level of nesting, even when using name, native HTMLElement and yarn develop (notice the third <slot> doesn't render)

   <script>
     class SlotTestNative extends HTMLElement {
       constructor() {
         super();
   
         // create a Shadow DOM
         this.root = this.attachShadow({ mode: 'closed' });
         this.root.innerHTML = `
           <h3>Content from the custom element. (inside HTMLElement)</h3>
             <h3>
               <slot name="content"></slot>
             <h3>
            <div>
              <span>nested - will the slot show?<span>
              <h3>
                <slot name="content"></slot>
             <h3>
           </div>
         `;
       }
     }
   
     customElements.define('slot-test-native', SlotTestNative);
   </script>

   <slot-test-native>
     <h3 slot="content">Content for the slot. (outside HTMLElement)</h3>
   </slot-test-native>

So just had to do a little refactoring to our website HTML to better honor these rules.

1. Removed extra <app-row> component to reduce extraneous nesting. _why use more JS when few JS do trick
2. Adjust styles to reflect new file structure (could probably clean this up some more)
3. Tested all major browsers (Edge, Chrome, FF, Safari) and all behaviors are consistent

TODO

1. Update docs to discuss Shadow DOM / <slot> best practices, probably best to after merge of Docs/issue 430 update technical documentation to reflect current project status #452
2. Remove <slot-test-native> example code after team review
3. Should track an issue to investigate removing puppeteers pre generated CSS. It looks like this includes ShadowDOM CSS which while great, we really don't want to have in the global scope anyway, which is the whole point. The trade-off I observed is that when using CSS-in-JS approach though, you'll likely be more susceptible to a flash of unstyled content. (FOUC), so will need to comment that YMMV - tracked in Roadmap To 1.0 And Beyond #418

[thescientist13]

@aholtzman
If you have a little time, could use a little help with style tweaks here to restore / cleanup the card styles given the new DOM structure we need to support our usage of <slot> here to match what it looked like before. 🙏

[thescientist13]

Unfortunately this wont work for yarn serve because this moves the <slot> away from being a direct descendent of the :host 😞

[thescientist13]

Something else i've come to realize about this issue is that when we pre-render a web component, the final HTML is not just the tags

<my-component></my-component>

but the tags plus whatever its contents render out to, e.g.

<my-component>
  <header>
    <h1>Lorum Ipsum</h1>
    <!-- etc -->
  </header>
</my-component>

The issue being that this pre-rendered markup is light DOM. When a web component mounts, it will by default attach a ShadowDOM. This means it will have both light and shadow DOM. This becomes an issue now because the light dom will now compete with the content projected into the Shadow DOM via <slot> because effectively that pre-rendered content will be slot content.

So short term there are some best practices and "rules" we can document for when <slot> is used which I have done. I have some ideas for how we can optimize for this case without having to burden the user. Let me fix the styles here first though and will track this for a future issue.