First Shadow DOMd webcomponent

[RyanHirsch]

This is the first web component that does nothing but slot the server markup. It ensures we have the proper build pipeline configured. It configures both a docker build pipeline using stage builds and webpack for compiling the client side code.

It creates a new dev npm script that will start in parallel both the existing nodemon functionality and a webpack process in watch mode. It still requires the developer to manually reload to see their changes.

[tbremer]

Should panel be in dependencies and not devDependencies?

_{Sent with GitHawk}

[RyanHirsch]

I don’t think so. We are using webpack to bundle it all which is all done in a dev environment. Moving it out of dev means it would be included in the final web server docker image which is not what we intend.

[RyanHirsch]

Web Components SSR

Server-side rendering of Web Components is possible, however, it is not as common or straightforward as React, Ember, Vue, or Angular. The most documented way to do this is with skatejs/ssr or run puppeteer. SSR is a bit of a challenge due to a special web component feature called Shadow DOM. Shadow DOM requires javascript execution to function, and during execution it creates a special DOM node that isn't serializable. There are a few exploratory techniques to create a <shadow-dom> component as a hack to provide serialization but it doesn't result in the same tree normal execution would and is definitely not a blessed, known strategy. Shadow DOM isn't a must use feature of Web Components it does give us access to slots (more on that later)

I think your main point though, is wanting to ensure

1. DOM is a fully populated when view sourcing
2. Content is available on screen as soon as possible

To that end this was my plan for the web components.

Create a candidate-card web component that would use Shadow DOM with slots (render props). This will allow the server to generate something like:

<candidate-card name="pete-buttigieg">
   <img class="candidate-image" src="/assets/images/pete-buttigieg.jpg" alt="Portrant of Pete Buttigieg.">
   <div class="candidate-meta"><h2 style="margin: 0; padding: 0;">Pete Buttigieg </h2>
   <p style="margin: .25rem 0; font-size: 1.25rem; font-weight: 500;">Delegate count:
   23</p>
</candidate-card>

The children of candidate-card in this example (img, div, p) are all available to be used in the component by leveraging a slot element.

class CandidateCard extends Component {
  ...
  template() {
    return h('slot');
  }
  ...
}

This will ultimately result in the following DOM being produced on the client

<candidate-card name="pete-buttigieg">
  #shadow-root
    <slot> pointer to the img, div, p nodes </slot>
  /shadow-root
   <img class="candidate-image" src="/assets/images/pete-buttigieg.jpg" alt="Portrant of Pete Buttigieg.">
   <div class="candidate-meta"><h2 style="margin: 0; padding: 0;">Pete Buttigieg </h2>
   <p style="margin: .25rem 0; font-size: 1.25rem; font-weight: 500;">Delegate count:
   23</p>
</candidate-card>

I've already shown today that shipping markup containing a custom element is ultimately just rendered as a "div". Which means that this slotting strategy will fulfill what I believe the two goals are for the default display of the candidate information.

What then does Web Components buy us? Well it provides for encapsulation of the hover/click behavior of #5 and a strategy to leverage browser native components for rich client-side interaction and behavior. (It is also an excuse to use them) If the additional data and interaction must be fully SSR, we may want to change this strategy. Options include, not using Shadow DOM and attempting SSR or abandoning web components.

I will also note, that JSDOM has finished support for Custom Elements after having an open issue for 4 years this past weekend. So the SSR story may be getting better.

[RyanHirsch]

If reading through the SSR note, you ask why are we slotting at all, here is the beginning of the plan. Slot the initial/default display, but then replace that when the user interacts with the card. So basically the "details" wouldn't be SSR'd but the normal view is.

[tbremer]

The script start is only used in dev, so it's fine to remove it if dev becomes the default script. Or move the contents of dev into start. Whatever is fine.

[RyanHirsch]

Updated the dockerfile to call start and updated the start command

[tbremer]

I get an error here, maybe because CustomElementConstructor is not pulled in from anywhere?

[RyanHirsch]

It is an interface from the dom library specified in the tsconfig.json, it shouldn't error for you 😞

[tbremer]

🤷‍♂