Component signature #385
Merged
Component signature #385
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adds backwards-compatible support for component `Signature`s per [Ember RFC #0748][rfc]. The public API of `Component` is now *more* permissive than it was previously, because it changes the type parameter to be an unconstrained generic `<S>` (for "signature") which can accept *either* the existing `Args` types *or* a new `Signature` which includes `Args` and adds `Blocks` and `Element`. [rfc]: emberjs/rfcs#748 The `Args` part of the new signature work exactly like the old args-only type did. The `Blocks` and `Element` parts of a signature are inert from the perspective of TypeScript users who are not yet using [Glint][glint], but Glint users will benefit directly once Glint releases an update which can requires a version of `@glimmer/component` incorporating this change. [glint]: https://github.com/typed-ember/glint Since this change is backwards compatible, we can deprecate the non-`Signature` form at a later time when we are ready for a 2.0 release. To validate these changes, with the relatively complicated type machinery they require under the hood, this also introduces the `expect-type` type testing library, rewrites the existing type tests using it, and introduces new type tests for all supported forms of the `Signature`.
|
Would love a review not only from core Glimmer folks but also from @dfreeman. |
chadhietala
reviewed
Mar 23, 2022
| interface FullLongSig { | ||
| Args: { | ||
| Named: Args; | ||
| Positional: []; |
|
LGTM |
jamescdavis
reviewed
Mar 23, 2022
jamescdavis
reviewed
Mar 23, 2022
This provides the expected resolution within a component, but does not introduce a breaking change by requiring all callers to pass a type parameter. Co-authored-by: James C. Davis <jamescdavis@gmail.com>
dfreeman
reviewed
Mar 24, 2022
There was a problem hiding this comment.
This looks great; thanks for getting it implemented @chriskrycho! Just a couple questions around type visibility that the answer to might be 'nope, this is exactly how we want it already'
jamescdavis
reviewed
Mar 24, 2022
Co-authored-by: James C. Davis <jamescdavis@gmail.com>
|
Note for myself: looks like once we land this I'll need to back-port it to the v1.x branch so we can cut a v1.1 release. |
dfreeman
reviewed
Mar 25, 2022
Co-authored-by: Dan Freeman <dfreeman@salsify.com>
chriskrycho
added a commit
that referenced
this pull request
Mar 31, 2022
Backport component signature (#385) to v1.x
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds backwards-compatible support for component
Signatures per Ember RFC #0748. The public API ofComponentis now more permissive than it was previously, because it changes the type parameter to be an unconstrained generic<S>(for "signature") which can accept either the existingArgstypes or a newSignaturewhich includesArgsand addsBlocksandElement.The
Argspart of the new signature work exactly like the old args-only type did. TheBlocksandElementparts of a signature are inert from the perspective of TypeScript users who are not yet using Glint, but Glint users will benefit directly once Glint releases an update which can requires a version of@glimmer/componentincorporating this change.Since this change is backwards compatible, we can deprecate the non-
Signatureform at a later time when we are ready for a 2.0 release.To validate these changes, with the relatively complicated type machinery they require under the hood, this also introduces the
expect-typetype testing library, rewrites the existing type tests using it, and introduces new type tests for all supported forms of theSignature.