Fix problem with transitive generics in Signatures#613
Fix problem with transitive generics in Signatures#613gossi wants to merge 2 commits intotyped-ember:mainfrom
Conversation
|
Thanks for opening this! The fact that CI is ✅ is a great initial sign – one of us will try to review in detail shortly. |
|
This should include, at a minimum, a new test case for the scenario this is intended to fix. Otherwise there's nothing to prevent us from flipping this back in the future and causing the same problem again (I'd also recommend coming up with a more specific title for this PR, since that's what will go in the release notes—we clearly already "allow generics in signatures" in the general case, since many built-ins like |
| ? NonNullable<Element> extends never | ||
| // ? Element extends null |
There was a problem hiding this comment.
this is a temporary revert. That is to write failing tests, which when switching back to the fix should be resolved.
| Positional: [] | ||
| }>(); | ||
|
|
||
| expectTypeOf<ComponentSignatureArgs<ElementReceiverSignature<null>>>().toEqualTypeOf<{ |
There was a problem hiding this comment.
Actually, this line is the problematic part here, I'd say. For what I think needs to be tested, is how the components are invoked, rather than the static definition?
That is, in invocation, this should be null. But this is obviously a failure:
Type 'null' does not satisfy the constraint 'string'.
To my knowledge, to properly test this, is to provide broken types. How to do that?
|
I added some tests. I copied over all the relevant types from I also left comments where I got stuck. I think, I need to test broken/invalid types, in a environment with correct types? |
gossi
changed the title
|
Hi @gossi! Just wondering if you’re planning to work on this at some point. |
|
I stopped. Iirc back then too much red showed up - and I didn't wanted to go through all this as it didn't seem much related to what I changed. However since then a lot changed on the glint repo itself. Feel free to pick it up. |
gossi
force-pushed
the
allow-generics-in-signatures
branch
from
420bdbc to
f79c9c5
Compare
|
I think resolving this issue is going to be a bit of a blocker for my team adopting Glint v2. |
…components Removes conditionals from the Element type pipeline that deferred for generic conditional types like ElementFromTagName<T>: 1. ComponentSignatureElement: returns Element directly instead of NonNullable<Element> extends never check (which deferred to unknown). 2. ComponentReturn: removes El extends Element ? El : null (another deferral point). El flows through directly. This fixes both reported errors from typed-ember#610: <Tag> and ...attributes now work correctly inside components with conditional Element types. Based on draft PR typed-ember#613 by @gossi.
…components Removes conditionals from the Element type pipeline that deferred for generic conditional types like ElementFromTagName<T>: 1. ComponentSignatureElement: returns Element directly instead of NonNullable<Element> extends never check (which deferred to unknown). 2. ComponentReturn: removes El extends Element ? El : null (another deferral point). El flows through directly. This fixes both reported errors from typed-ember#610: <Tag> and ...attributes now work correctly inside components with conditional Element types. Based on draft PR typed-ember#613 by @gossi.
…omponent signatures Two changes eliminate deferred conditional chains that collapsed ElementFromTagName<T> to unknown when T was generic: 1. ComponentSignatureElement: replace NonNullable<Element> extends never with Element extends null. The old NonNullable check deferred for unresolved conditionals; the new null check only fires for literal null (preserving null → unknown for ComponentLike equivalence). 2. ComponentReturn: replace El extends Element ? El : null with El extends null ? unknown : El. The old Element check deferred for conditional types; the new null check doesn't because null is concrete. Based on draft PR typed-ember#613 by @gossi.
…omponent signatures Two changes eliminate deferred conditional chains that collapsed ElementFromTagName<T> to unknown when T was generic: 1. ComponentSignatureElement: replace NonNullable<Element> extends never with Element extends null. The old NonNullable check deferred for unresolved conditionals; the new null check only fires for literal null (preserving null → unknown for ComponentLike equivalence). 2. ComponentReturn: replace El extends Element ? El : null with El extends null ? unknown : El. The old Element check deferred for conditional types; the new null check doesn't because null is concrete. Based on draft PR typed-ember#613 by @gossi.
…omponent signatures Two changes eliminate deferred conditional chains that collapsed ElementFromTagName<T> to unknown when T was generic: 1. ComponentSignatureElement: replace NonNullable<Element> extends never with Element extends null. The old NonNullable check deferred for unresolved conditionals; the new null check only fires for literal null (preserving null → unknown for ComponentLike equivalence). 2. ComponentReturn: replace El extends Element ? El : null with El extends null ? unknown : El. The old Element check deferred for conditional types; the new null check doesn't because null is concrete. Based on draft PR typed-ember#613 by @gossi.
|
@gossi @wagenet: this should now be resolved in the latest release of glint. Please have a look to see if your use cases agree! thanks, |
6 participants
Potential fix to #610
I was applying the fix as part of this PR locally on my PR emberjs/ember-element-helper#107 and see if in my type-test-component:
I was able to remove the line
{{!@glint-ignore}}and if the type linting still passes, which is the case.So, yes this is a potential fix, but I share the same concerns as @dfreeman this might come with side-effects.
So I'll make it a draft PR.