Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Activate strictBindCallApply and strictFunctionTypes compiler rules #2880

Merged
merged 2 commits into from
Apr 12, 2019

Conversation

lindner
Copy link
Contributor

@lindner lindner commented Apr 11, 2019

  • Improves types in api-channel and slot-consumer
  • Introduce option types for startRender and stopRender
  • Fix mismatched Map/object types in providedSlots
  • Use specific types in Literalizer

- Improves types in api-channel and slot-consumer
- Introduce option types for startRender and stopRender
- Fix mismatched Map/object types in providedSlots
- Use specific types in Literalizer
@lindner lindner requested a review from shans April 11, 2019 20:50
prototype: {toLiteral: () => TypeLiteral};
fromLiteral: (typeliteral: TypeLiteral) => Type;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a little hacky, but describes the current usage. Should ParticleSpec/PropagatedException implement Type/TypeLiteral instead?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better to templatize literalizer on the literal type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to parameterize Literalizer, but none of them survived the use of decorators with any fidelity.

I also started down the path of creating a new Literalizable interface but ran into the same issues with adding Types to EnityType (namely lack of static methods in interfaces microsoft/TypeScript#14600) Especially with generics.

Since the latter solution is preferred, but also much more invasive I'll spin those changes out to another cleanup issue.

@@ -415,7 +425,7 @@ export abstract class PECOuterPort extends APIPort {
UIEvent(@Mapped particle: recipeParticle.Particle, @Direct slotName: string, @Direct event: {}) {}
SimpleCallback(@RemoteMapped callback: number, @Direct data: {}) {}
AwaitIdle(@Direct version: number) {}
StartRender(@Mapped particle: recipeParticle.Particle, @Direct slotName: string, @ObjectMap(MappingType.Direct, MappingType.Direct) providedSlots: {[index: string]: string}, @List(MappingType.Direct) contentTypes: string[]) {}
StartRender(@Mapped particle: recipeParticle.Particle, @Direct slotName: string, @ObjectMap(MappingType.Direct, MappingType.Direct) providedSlots: Map<string, string>, @List(MappingType.Direct) contentTypes: string[]) {}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the new checks caught this type mismatch. (Should be Map<string,string>)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

Copy link
Contributor

@shans shans left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(But please try to get the literalizer templated before submitting - that's the long-term direction that toLiteral/fromLiteral needs to go in)

prototype: {toLiteral: () => TypeLiteral};
fromLiteral: (typeliteral: TypeLiteral) => Type;
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better to templatize literalizer on the literal type.

@@ -415,7 +425,7 @@ export abstract class PECOuterPort extends APIPort {
UIEvent(@Mapped particle: recipeParticle.Particle, @Direct slotName: string, @Direct event: {}) {}
SimpleCallback(@RemoteMapped callback: number, @Direct data: {}) {}
AwaitIdle(@Direct version: number) {}
StartRender(@Mapped particle: recipeParticle.Particle, @Direct slotName: string, @ObjectMap(MappingType.Direct, MappingType.Direct) providedSlots: {[index: string]: string}, @List(MappingType.Direct) contentTypes: string[]) {}
StartRender(@Mapped particle: recipeParticle.Particle, @Direct slotName: string, @ObjectMap(MappingType.Direct, MappingType.Direct) providedSlots: Map<string, string>, @List(MappingType.Direct) contentTypes: string[]) {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

@lindner
Copy link
Contributor Author

lindner commented Apr 12, 2019

Deferring templatization. I agree that it is the better way to go; despite Typescript being not amenable to a simple solution...

@lindner lindner merged commit 37d3661 into PolymerLabs:master Apr 12, 2019
sjmiles pushed a commit to sjmiles/arcs that referenced this pull request Apr 23, 2019
…olymerLabs#2880)

* Fix firebase strictFunctionTypes violation
* Activate strictBindCallApply and strictFunctionTypes compiler rules
 - Improves types in api-channel and slot-consumer
 - Introduce option types for startRender and stopRender
 - Fix mismatched Map/object types in providedSlots
 - Use specific types in Literalizer
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants