Not sure about this one since this apparently didn't catch any real-word issues. But it will require props changes where people accept mutable props even though they only use it as readable.

So I sympathize but TypeScript is all about making pragmatic decisions considering type-safety.

the default prop 'ref' in components be addressed here?

Yep.

What should we adress about forwardRef?

I'd much rather be able to decide how to let TS know about how React can use my custom elements, because the example above might silence errors but at the same time it also makes it easy to forget to add type definitions that are precise, e.g.:

import 'types-react' // types: rc
import 'types-react-dom' // types: rc

type Color = NonNullable<React.CSSProperties["color"]>

class MyColorElement extends HTMLElement {
  inner = this.attachShadow({ mode: "open" })
  color?: Color

  static get observedAttributes() {
    return ["color"]
  }

  constructor() {
    super()
  }

  attributeChangedCallback(name: string, oldValue: unknown, newValue: unknown) {
    if (name === "color" && oldValue !== newValue) {
      const element = this.inner.querySelector("input")
      if (!element) return
      element.value = newValue as string
      this.color = newValue as string
    }
  }

  connectedCallback() {
    const color = this.getAttribute("color")

    this.inner.innerHTML = /* html */ `
      <label>
        <span>Colorize!</span>
        <input value="${color ?? ""}">
        <button>Apply</button>
      </label>
    `

    this.inner.querySelector("button")?.addEventListener("click", () => {
      const value = this.inner.querySelector("input")?.value

      if (!value) return

      this.color = value

      const payload = new CustomEvent("ColorChange", {
        detail: value,
        bubbles: true,
        composed: true,
      })

      this.dispatchEvent(payload)
    })
  }
}

window.customElements.define("my-color", MyColorElement)

export const MyColor = "my-color"

interface MyCustomEvent<D = unknown, C = unknown, T = unknown>
  extends CustomEvent<D> {
  currentTarget: C & EventTarget
  target: T & EventTarget
}

interface ColorChangeEvent<T = Element> extends MyCustomEvent<Color, T> {}

type ColorChangeEventHandler<T = Element> = {
  bivarianceHack(event: ColorChangeEvent<T>): void
}["bivarianceHack"]

interface MyColorHTMLAttributes<T> extends React.HTMLAttributes<T> {
  color?: Color | undefined
  onColorChange?: ColorChangeEventHandler<T> | undefined
  onColorChangeCapture?: ColorChangeEventHandler<T> | undefined
}

export interface MyColorJSXIntrinsicElement {
  "my-color": React.DetailedHTMLProps<
    MyColorHTMLAttributes<MyColorElement>,
    MyColorElement
  >
}

declare module "react" {
  namespace JSX {
    interface IntrinsicElements extends MyColorJSXIntrinsicElement {}
  }
}

const color: Color = "black";

<MyColor
  color={color}
  onColorChange={(event) => {
  	event.target
  	//    ^?
  	event.currentTarget
  	//    ^?
  	event.currentTarget.color
  	//    			    ^?
  	event.detail
  	//    ^?
  }}
  onClick={(event) => {
  	event.target
  	//    ^?
  	event.currentTarget
  	//    ^?
  	event.currentTarget.color
  	//                  ^?
  }}
/>;

type MyColorRef = React.ComponentRef<typeof MyColor>
//   ^?

<my-color
  color={color}
  onColorChange={(event) => {
  	event.target
  	//    ^?
  	event.currentTarget
  	//    ^?
  	event.currentTarget.color
  	//    			    ^?
  	event.detail
  	//    ^?
  }}
  onClick={(event) => {
  	event.target
  	//    ^?
  	event.currentTarget
  	//    ^?
  	event.currentTarget.color
  	//                  ^?
  }}
/>;

type My_ColorRef = React.ComponentRef<'my-color'>
//   ^?

TypeScript Playground

Similarly, your CSS custom properties example also isn't super precise. See https://github.com/frenic/csstype#what-should-i-do-when-i-get-type-errors.

Now, that might be fine for you. But to make that the default experience for everyone is not the right call, IMO.

I never suggested making my exact code the default experience for everyone. You should absolutely be able to define more precise types if you want. See forked playground.

All I'm saying is that raising these type errors by default is undesirable and honestly a bad look for React. It's equivalent to if (hypothetically) all data attributes raised type errors by default, forcing everyone to type them precisely or add workarounds. I expect data attributes, custom elements, and custom CSS properties to all work out-of-the-box without errors, since these are all platform features specifically designed to be extended by authors.

You should absolutely be able to define more precise types if you want.

But your suggestion would default everybody to have loose types with regards to DOM attributes.

It's equivalent to all data attributes raising type errors by default, forcing everyone to type them precisely or add workarounds.

data-* attributes do not raise type errors by default (e.g. <div data-whatever="my-choice" />. There's only one bug regarding them tracked in #69864 and waiting for a contributor.

data-* attributes do not raise type errors by default

Yes, I'm saying that custom elements raising type errors is equivalent to if data attributes also did the same.

Isn't it basically the same situation? By default, everyone has loose types (but no type errors) for data attributes.

Isn't it basically the same situation? By default, everyone has loose types (but no type errors) for data attributes.

data-* attributes have the string type by (HTML) design. data-* attributes are intended for extending behavior. That doesn't mean you should also allow any attributes on every Element.

If we loosen the types, consumers cannot make them stricter. And even if they could, it's probably not the default most people want.

On the flipside, the behavior you want can be implemented today:

import * as React from 'react'

declare module 'react' {
    interface HTMLAttributes<T> {
        [anyProp: string]: unknown
    }

    namespace JSX {
        interface IntrinsicElements {
            [anyElement: string]: Record<keyof any, unknown>
        }
    }
}

<div foo />;
<this-doesnt-exist />;

// Probably meant `type` but is now permitted by types
<button typ="submit" />;

Playground Link

Is the action prop for the form element meant to be able to accept an async function (or more specifically a (formData: FormData) => void | Promise)?

Yes, it just happened to work because of TypeScript quirks where functions with any return type are assignable to functions with the void return type.

Added explicit support in #70197 to not rely on this quirk.

Ah nvm, I see here: https://react.dev/blog/2024/04/25/react-19-upgrade-guide#installing, we need to map the types-react package.

And so are the types: https://www.npmjs.com/package/@types/react/v/19.0.0

Landed in #69022