Skip to content

Instantly share code, notes, and snippets.

View justinfagnani's full-sized avatar

Justin Fagnani justinfagnani

943 followers · 0 following
View GitHub Profile
@justinfagnani
justinfagnani / Scoped-Custom-Element-Registries.md
Last active June 26, 2023 02:08
Scoped Custom Element Registries

Outdated - current proposal is at https://github.com/justinfagnani/scoped-custom-elements

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.

@justinfagnani
justinfagnani / slot-controller.ts
Created March 31, 2022 22:33
SlotController
import type {ReactiveController, ReactiveControllerHost} from 'lit';
/**
* A reactive controller that updates a host when slotted content changes and
* provides helper methods for checking and getting assigned slot content.
*/
export class SlotController implements ReactiveController {
private _host: ReactiveControllerHost & Element;
private _slotNames?: ReadonlyArray<string>;
@justinfagnani
justinfagnani / README.md
Last active April 21, 2022 08:45
Inline JavaScript Modules Definitions

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.
@justinfagnani
justinfagnani / mixins.md
Last active April 13, 2022 12:14
Maximally Minimal Mixins
@justinfagnani
justinfagnani / example.ts
Created March 4, 2020 22:16
Observable LitElement
class ExampleElement extends ObservableLitElement {
@property()
src: string;
@observe('src')
protected async _onSrcChange() {
// fetch the new URL...
}
}
@justinfagnani
justinfagnani / apollo-controller-connected-event.ts
Created April 26, 2021 01:24
Apollo Controllers
import {ApolloClient, NormalizedCacheObject} from '@apollo/client/core';
/**
* Fired when an Apollo controller is connected to the document tree via its
* host. Listeners should supply an Apollo client by setting the `client`
* property on the event.
*/
export class ApolloControllerConnectedEvent extends Event {
static readonly eventName = 'apollo-controller-connected';
@justinfagnani
justinfagnani / Async Module Initialization.md
Last active January 26, 2021 08:24
Async Module Initialization with Inline Modules

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.

@justinfagnani
justinfagnani / README.md
Last active February 8, 2020 05:38

This is a reproduction for https://bugs.chromium.org/p/chromium/issues/detail?id=1050221

To reproduce:

  1. Download gist
  2. run npm i
  3. run npm start

Chrome will start, cycle through some async tasks, and print the duration to the document and the terminal running node. On my laptop it takes ~500ms.

Next, run npm start again, bug switch back to the terminal as soon as Chrome launches. There should be enough time to put Chrome in the background before the task completes. The tasks should either never start or never complete. If you put Chrome in the foreground, the tasks will finish quickly.

@justinfagnani
justinfagnani / index.html
Created December 14, 2019 04:02 — forked from jridgewell/index.html
Creating an TreeWalker, DOM element, and setting a walker's currentNode #jsbench #jsperf (https://jsbench.github.io/#26a49a6033a8a5de00d00e05bf2cb275) #jsbench #jsperf
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<title>Creating an TreeWalker, DOM element, and setting a walker's currentNode #jsbench #jsperf</title>
<script src="https://cdnjs.cloudflare.com/ajax/libs/benchmark/1.0.0/benchmark.min.js"></script>
<script src="./suite.js"></script>
</head>
<body>
<h1>Open the console to view the results</h1>
@justinfagnani
justinfagnani / index.html
Last active September 5, 2019 17:31 — forked from jridgewell/index.html
Directive Implementations (https://jsbench.github.io/#4f3d62eb97bd1c992a5257d34fcebea0) #jsbench #jsperf
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<title>Directive Implementations</title>
<script src="https://cdnjs.cloudflare.com/ajax/libs/benchmark/1.0.0/benchmark.min.js"></script>
<script src="./suite.js"></script>
</head>
<body>
<h1>Open the console to view the results</h1>