Generic type parameter for props (P) comes before data (D)

I'm a bit confused because currently D comes before P. Are you suggesting that Props should come before Data, or the other way around?

Generic type parameter P has defaults

I guess it should default to {} instead. I gave it the Record<string, any> default mostly so that I can omit the generics and get a magical this when I don't want to bother with specifying types. Changing to to {} would force users to always fully type their props. It may be a bit too strict but maybe that's a good idea.

Vue is currently non-generic

Yeah this part is very much just a proof of concept right now. We will revisit proper typing for it when we finalize it. The vue package will likely be just the 2.x compat build which will use the 2.x typings...

.d.ts files are produced using dts-bundle

Good to know, I wasn't aware of API extractor before. Will look into it.

Build process could leverage project references.

I'm not sure if I understand the proposal - I haven't seen the need for project references so far. Maybe we will need it later? Are you suggesting we place a tsconfig.json in each package and reference the root tsconfig.json?

from core.

Generic type parameter for props (P) comes before data (D)

I'm a bit confused because currently D comes before P. Are you suggesting that Props should come before Data, or the other way around?

Whoops! Fixed. Yes, I meant P should come before D.

Generic type parameter P has defaults

I guess it should default to {} instead. I gave it the Record<string, any> default mostly so that I can omit the generics and get a magical this when I don't want to bother with specifying types. Changing to to {} would force users to always fully type their props. It may be a bit too strict but maybe that's a good idea.

I think that users looking for Vue/TypeScript will prefer the stricter experience. Even so, if we can do some more inference here that will probably strike a better balance of writing less while still getting better types. I've opened up microsoft/TypeScript#27584 so we can track that.

Vue is currently non-generic

Yeah this part is very much just a proof of concept right now. We will revisit proper typing for it when we finalize it. The vue package will likely be just the 2.x compat build which will use the 2.x typings...

That sounds reasonable to me, though I'm wondering if the idea is to just have two separate builds, or if the Vue 2.x functionality is available out of the box.

Build process could leverage project references.

I'm not sure if I understand the proposal - I haven't seen the need for project references so far. Maybe we will need it later? Are you suggesting we place a tsconfig.json in each package and reference the root tsconfig.json?

That's basically it, but I wouldn't get hyper-focused on that if it's not a problem. It can just give you faster builds; if A depends on B depends on C, a change to Cthat doesn't affect its public API means that neitherAnorB` need to be rebuilt if their outputs are built and already up-to-date.

from core.

props duplication & validation

From #2 (comment)

A few obvious things to improve here:

1. If the user provided a Props interface but didn't specify the static props options, the props will still be merged onto `this` in types but not in implementation.

2. User has to specify the Props interface for compile-time type checking AND the props options for runtime type checking. It'd be nice if the compile-time types can be inferred from the props options like it does for 2.x, although I haven't figured out how to do that yet.

I'm a little curious over what the rationale is to only proxy specified props. What are the current design limitations that prevent this.

Note the reason we are designing it like this is because we want to make plain ES usage and TS usage as close as possible. As you can see, an ES2015 version of the above would simply be removing the interfaces and replacing the static options with an assignment.

If we can get a decorator implementation that matches the new stage-2/3 proposal, we can provide decorators that make it simpler:

class Foo extends Component {
  @data foo: string = 'hello'
  @prop bar: number = 123
}

I agree that this'd be nice, though, the problem here is that now there's nowhere to keep track of props externally. So while you get internal validation, there's not a way to keep track of which props you're aggregating. I'll check with the team to get some thoughts around this.

from core.

Even so, if we can do some more inference here that will probably strike a better balance of writing less while still getting better types. I've opened up microsoft/TypeScript#27584 so we can track that

Actually, I realized that props are specified statically (as they should be), not via a super() call. So never mind that!

from core.

I'm a little curious over what the rationale is to only proxy specified props. What are the current design limitations that prevent this.

When a component doesn't declare props, the consumer of the component can pass arbitrary props to it that may conflict with the component's own data or methods. With declared props we can check duplication and warn at development time.

from core.

Closing since we are dropping the Class API.

from core.