Type of Change
Summary
To build off of #3 , the next level of granularity to try and achieve in hydration strategies is partial hydration, which is
Use knowledge of the client vs server to only ship code / serialize data needed in the browser.
Details
Which I basically interpret to mean that given a component like this
class Header extends HTMLElement {
constructor() {
super();
if (this.shadowRoot) {
const button = this.shadowRoot.querySelector('button');
button.addEventListener('click', this.toggle);
}
}
connectedCallback() {
if (!this.shadowRoot) {
this.attachShadow({ mode: 'open' });
this.shadowRoot.innerHTML = this.render();
}
}
toggle() {
alert('this.toggle clicked!');
}
render() {
return `
<style>
.header {
background-color: #192a27;
min-height: 30px;
padding: 10px;
font-size: 1.2rem;
}
...
</style>
<header class="header">
...
</header>
`;
}
}
export { Header };
customElements.define('wcc-header', Header);
Since there are no props or state, we should be able to infer
- Only one render is needed, which can be handled via declarative shadow dom
- We still need the event handler
So in an ideal world, this is what would actually be shipped to the browser
class Header extends HTMLElement {
constructor() {
super();
if (this.shadowRoot) {
const button = this.shadowRoot.querySelector('button');
button.addEventListener('click', this.toggle);
}
}
toggle() {
alert('this.toggle clicked!');
}
}
export { Header };
customElements.define('wcc-header', Header);
Type of Change
Summary
To build off of #3 , the next level of granularity to try and achieve in hydration strategies is partial hydration, which is
Details
Which I basically interpret to mean that given a component like this
Since there are no props or state, we should be able to infer
So in an ideal world, this is what would actually be shipped to the browser