@mattdamon108 take a look and ignore syntax and the rough state. Curious if this mechanism is enough to represent concisely what's required to have different types for different Dom elements. How about creating a little mock like the example in the PR, without putting all the fields only some to test the idea, see how it looks like?

@cannorin possibly relevant for conversion of TS bindings.

CC @zth

I like this! This is going to be helpful in many cases.

How about creating a little mock like the example in the PR, without putting all the fields only some to test the idea, see how it looks like?

Got it. I’ll make some example for it. The sample cases would be the representation of types for dom props and dom events.

If I read the code correctly, using label as “dotdotdot” means the single extension, right? Not like {…a, …b}

If I read the code correctly, using label as “dotdotdot” means the single extension, right? Not like {…a, …b}

Correct. Only one extension at the moment.
Curious if more are required. Can be generalized in that case.

If I read the code correctly, using label as “dotdotdot” means the single extension, right? Not like {…a, …b}

Correct. Only one extension at the moment. Curious if more are required. Can be generalized in that case.

Maybe or Maybe not. Not sure for now, but I think the single extension seems enough for the dom definition at this moment.

added some example of record extension for dom elements
410f3c2

Added support for multiple "dotdotdot"

Some design questions about fields possibly repeating.

This is now possible:

  type t1 = {x: int}
  type t2 = {dotdotdot: t1, x: string}

What it creates, is a type that cannot be used, as it contains x twice.

Two possible ways are:

1. give an error
2. make t2 override the definition in t1

@cristianoc From the code generation perspective, it is probably better to make t2 override it (that needs less corner-case checking).

@cristianoc From the code generation perspective, it is probably better to make t2 override it (that needs less corner-case checking).

We can always relax that later if needed (without causing braking changes).
While if we start permissive it's more difficult to revert.

We can always relax that later if needed (without causing braking changes).
While if we start permissive it's more difficult to revert.

We are going to encounter this corner case very often because many TS users write something like this:

interface A {
  foo: any;
  ...
}

interface B extends A {
  foo: string;
}

So I guess it is better to start permissive in this case?

We can always relax that later if needed (without causing braking changes).
While if we start permissive it's more difficult to revert.

We are going to encounter this corner case very often because many TS users write something like this:

interface A {
  foo: any;
  ...
}

interface B extends A {
  foo: string;
}

So I guess it is better to start permissive in this case?

The tooling can get special capabilities. In fact it could even live inside the compiler, so it's easier to iterate on these things in a PR.
This PR is for direct users.

About surface syntax, this is perfectly valid object type definition, and trying to support ... for records would simply be ambiguous.

type xy = {
  "x": float,
  "y": float,
}
type z = {
  "z": float,
}

type xyz = {
  ...xy,
  ...z,
}