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

Issues with new modifier helper #570

Closed
simonihmig opened this issue May 2, 2023 · 2 comments
Closed

Issues with new modifier helper #570

simonihmig opened this issue May 2, 2023 · 2 comments

Comments

@simonihmig
Copy link
Contributor

Updating Glint to the new stable version 🎉 and removing my old any-based hacks due to the previously missing modifier-helper in this PR, I am seeing two issues come up here:

  1. Type instantiation is excessively deep and possibly infinite. - this seems to be related to my use of a conditional modifier here, that error does not pop up when not using this pattern
  2. Expected 1 arguments, but got 3. - this seems to be also an edge case, when applying the modifier helper on the imported on modifier (using @types/ember__modifier, have not tried native types yet). {{modifier "on" ...}} does not work due to [Bug] The on modifier does not work with the modifier helper emberjs/ember.js#19869
@dfreeman
Copy link
Member

dfreeman commented May 2, 2023

For (1), do you have any examples that aren't using the on modifier? In general conditional modifiers like that should work, and I'm only seeing that excessively deep and possibly infinite message for cases where there are other type errors in play.

For (2), unfortunately I think we may be fundamentally unable to make on work well with {{modifier}}. The types for {{modifier}} and friends are fairly monstrous, and the way on's eventName argument is used to determine the Event subtype that the callback receives is more than TS's inference can handle—it ends up picking a (seemingly) arbitrary {{modifier}} signature that just doesn't work properly.

For the case you've linked there, have you considered using a single custom modifier to manage your event listeners? I suspect that would be easier to type, as well as avoiding runtime issues with emberjs/ember.js#19869

@simonihmig
Copy link
Contributor Author

For (1), do you have any examples that aren't using the on modifier?

No, it seems to come up only with on!

For the case you've linked there, have you considered using a single custom modifier to manage your event listeners

I just tried that, and indeed it works nicely and avoids all the mentioned problems! Thanks for the suggestion!

Gonna close this issue then, as it seems there isn't anything actionable left...

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

No branches or pull requests

2 participants