dglazkov

/**
 * @license
 * Copyright 2024 Google LLC
 * SPDX-License-Identifier: Apache-2.0
 */

import { board } from "@google-labs/breadboard";

export default await board(({ text }) => {
  return { text };

dglazkov

{
  "edges": [
    {
      "from": "input-2",
      "to": "promptTemplate-1",
      "out": "topic",
      "in": "topic"
    },
    {
      "from": "secrets-5",

dglazkov

{
  "edges": [
    {
      "from": "jsonata-5",
      "to": "output-6",
      "out": "result",
      "in": "headlines"
    },
    {
      "from": "xmlToJson-4",

dglazkov

{
  "edges": [
    {
      "from": "input-1",
      "to": "prompt-template-6",
      "out": "text",
      "in": "topic"
    },
    {
      "from": "secrets-8",

dglazkov

#The Shadow DOM Diaries

Feature design is hard, and takes time. With time, it doesn't matter how public and consistent you are with communication during design process. In the end, it all will look like a jumbled mess of emails and bug comments. That seems bad. To make things less bad, I decided to start writing these little docs. Here they are. I may add more. Or not. Whatevs.

Sometimes You Need to Build a Larger Thing First looks back at the road we've traveled.

Shadow DOM Evolution outlines the path forward.

Why Do We Only Allow Children in Insertion Points provides a glimpse into the reasoning behind current insertion point design.

dglazkov

#Composition is the Goal

I see several discussions now that vacillate around on encapsulation qualities of Shadow DOM and the flavors thereof. It's all my fault. I stuck encapsulation into the problem statement of the spec. I even glued the somewhat irrelevant term functional encapsulation on top of it. What a dork.

It was a couple of years ago, when one of my colleagues read the spec and noted: "Dude, it's like your story and whatever, but the way you tell it, Shadow DOM is not about encapsulation. It's about composition". The world went blank around me. I was blinded by insight.

My hipster colleague was right, of course. Encapsulation is just a tool. Composition is the goal.

This is why the people who'd never used Shadow DOM in real life get really hung up on the details of encapsulation, while those who actually use Shadow DOM stare at them quizzically.

dglazkov

Definition of the Multiple-actor Problem

The Multiple-actor Problem (MAP) occurs in a web application that contains multiple bits of code, each assuming that they are the only actor in the document. The problem manifests when these assumptions conflict with each other.

Some examples:

• A web app is written in framework A, then later an analytics script B is added. A makes assumptions about lifetime of elements and handling of events. B is not aware of these assumptions and subtly violates them, causing jank (example)
• A web app is written using framework A. Attempting to introduce a widgets built using framework B results in weird errors, because B is violating A's assumptions about control of document state (examples 1, [2](http://stackoverflow.com/questions/254

dglazkov

class Me {
  constructor() {
    e1 = new Me;
    super();
    e2 = new Me;
  }
}

dglazkov

// stays as is
class FontDescription;

// stays as is
class FontData;

class FontContext : public RefCounted<FontContext> {
PassRefPtr<FontData> getFontData(const FontDescription&);
	void addFontDataProvider(const AtomicString& familyName,
                               PassRefPtr<FontDataProvider>);

dglazkov

/*  Scenario A:
    The most naive example of what a developer expects.
*/
div.innerHTML = '<foo-bar></foo-bar>';
// <foo-bar>'s readyCallback must be called here.
div.firstChild.methodOnFooBar();

/*  Scenario B:
    HTMLInputElement as Custom Element, Part 1.
*/