Instantly share code, notes, and snippets.

View example.js
import {LitElement, html} from 'lit-element';
import {UseWindowSize} from './useWindowSize.js';
class extends UseWindowSize()(LitElement) {
render() {
return html`
<p>
width: ${window.innerWidth}
height: ${window.innerHeight}
</p>
View preemptible-js.md

Preemptible JavaScript Functions

Can we allow JS functions to opt-in to be prempted?

Synchronous

An expensive synchronous function will jank the UI:

function expensive() {}
View example-worker.ts
export const a = 'hello';
export const f = (a: any, b: any, c: any) => {
return {
a, b, c
};
};
View README.md

Inline JavaScript Module Definitions

Motivation

Domenic's blöcks proposal outlines a way to conveniently define functions that run in another worker/worklet as an inline, non-capturing scope, function body.

Blöcks as proposed have a few open questions and lack a few features that could generalize them to more use cases and with more practical ergonomics.

  • Blöcks don't allow static imports, which makes it harder for them to import neccessary library code. They must rely on dynamic import, which is somewhat more difficult to statically analyzer.
View mixins.md
View Async Module Initialization.md

Async Module Initialization with Inline Modules

The Problem

Modules may need to load non-JS resources that would clearly categorized as dependencies - the module is not truly ready until those resources are (example: templates for UI components). Loading APIs, like fetch() are asynchronous, and there is currently no way to make a module wait for asynchronous calls.

The Problem with Top-Level await

Top-level await, which would block execution within a module on a await expression, has been proposed as a way to solve this problem. It has a critical problem as highlighted here by Rich Harris.

View Scoped-Custom-Element-Registries.md

Scoped Custom Element Definitions

Overview

Scoped Custom Element definitions is an oft-requested feature of Web Components. The global registry is a possible source of name collisions that may arise from coincidence, or from an app trying to define multiple versions of the same element, or from more advanced scenarios like registering mocks during tests, or a component explicitly replacing an element definition for its scope.

Since the key DOM creation APIs are global, scoping definitions is tricky because we'd need a machanis to determind which scope to use. But if we offer scoped versions of these APIs the problem is tractable. This requires that DOM creation code is upgraded to use the new scoped APIs, something that hopefully could be done in template libraries and frameworks.

This proposal adds the ability to construct CustomElementRegistrys and chain them in order to inherit custom element definitions. It uses ShadowRoot as a scope for definitions. ShadowRoot can be associated with a

View findIndexAsync.js
async function findIndexAsync(promises, predicate) {
let i = 0;
for await (const p of asyncIterate(promises)) {
if (predicate(p)) {
return i;
}
i++;
}
}
View custom-element-conformance.js
const NativeHTMLElement = window.HTMLElement;
const documentWrite = document.write;
const documentOpen = document.open;
window.HTMLElement = class extends NativeHTMLElement {
constructor(...args) {
console.assert(args.length === 0);
super();
View index.html
<!doctype html>
<html>
<head>
<script src="shadow-root.js"></script>
</head>
<div>
<div slot="main">
I'm some projected content.
</div>
<shadow-root>