Land in experimental-directives branches for review:

• until (in progress)
• asyncAppend
• asyncReplace
• templateContent (may punt)
• unsafeHTML (may punt)
• unsafeSVG (may punt)
• live
• ifDefined

To ensure the logic for numbering is correct, ie: the regex for parsing <!--lit-bindings x--> was incorrect at one point.

Using the lit-html hydration branch, we should set up integration test infrastructure so that we can run unit tests that do server rendering, hydrate the results on the client, and check assertions on the hydrated results.

The working assumption is that these will be Karma tests utilizing a proxy to serve up the server rendered HTML.

We directly call render() right now. We need to codify this in the design doc.

Description

lit-ssr needs to recognize property bindings to user-defined reflect: true properties on LitElements and automatically serialize those to their corresponding attributes.

Acceptance Criteria

• Tests that demonstrate correct serialization of user-defined reflecting properties to attributes are checked in and passing.

On the client, this code will not result in script execution:

const result = html`<script>alert('hi')</script>`;
render(result, container);

However, when rendering the same template via render-lit-html, the script will be emitted into the page and executed when parsed on the client. The SSR code should (optionally) identify <script> tags and mark with a type="disabled" or similar attribute to prevent script execution, to maintain the same guarantees client-side security guarantees when server-rendering.

• Email app
• Use bespoke LitElement components (e.g. not MWC)
• Use declarative ShadowRoot
• Test server rendering & client-side hydration

Can you add an online demo

• Write benchmarks
• Decide on template or element or both (SEO impact)
• Design shard styles (design doc & public explainer?)
• Implement shared styles
• Implement hacker-news shadow-dom app

Mainly just test that they don't render and then close the loop in lit-html hydration.

Done: repeat directive works when pre-rendering a template.

Let's benchmark hydration of pre-rendered html using lit-html VS. rendering of the same page using normal lit-html. This can give us insights on the costs of the hashing scheme and other additions made for hydration.

Components like <lit-virtualizer> may need to render differently on the server and client. It's possible that existing component SSR, renderLight(), plus whatever we do for directives may cover the cases here, but we should verify and prototype before releasing lit-virtualizer.

Done: Add @frankiefu's gmail app as a benchmark fixture in the lit-ssr project. Create benchmarks to measure (1) pre-rendering and (2) hydration of the app.

ElementRenderer might need changes to enable this.

There's an ordering issue in that we want to set attributes before the element renders so that the element can use them, but we need reflected attributes to be streamed before closing the start tag.

Implement style scoping for pre-rendered custom elements. We already generate a scoped stylesheet that covers all defined custom elements, now we need to add the scoping classes to all of those elements.

We need to keep track of the slotted element's original locations for shadow root rehydration.

• lit-element renderLight
• Implement lit-hacker-news light-dom rendered app
• benchmark app

We should make a lit/ subfolder.

In render.ts we have handleNode can render an element including finding the correct renderer for it, handling attributes, etc., LitHtmlChildRenderer also needs to do this, so we should expose a common element rendering function.