Introduce {{helper}}
and {{modifier}}
helpers
#553
Merged
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.
High Level
The headline here is adding
{{helper}}
and{{modifier}}
, but the bulk of the diff is actually internal changes to improve inference characteristics for those two helpers and the existing{{component}}
one.Note that the types for these helpers are intrinsically super complicated because their runtime behavior is super complicated, and we're unlikely to ever get 100% fidelity. The error messages can also be heinous, but we provide hints where possible, and this change isn't making matters any worse than they already were on that front with
{{component}}
.Details
I had a whole novel written up here and accidentally ⌘-Red, so... 😭
The abridged version is that this PR adds a new DSL method
resolveForBind
as a sibling toresolve
andresolveOrReturn
. In concert with that, it introduces abind-invokable
special form. When we encounter a helper declared to bebind-invokable
, we treat its first argument specially and hand it off toresolveForBind
, which has two effects:{{component}}
(and now{{helper}}
and{{modifier}}
) to account for different resolution semantics{{component}}
(and now{{helper}}
and{{modifier}}
) can function just in terms of Glint's internal function representation of invokables, not needing to juggle both the translation and the binding semanticsOther Notes
This also adds a
WithBoundPositionals
utility type as a counterpart toWithBoundArgs
, and as part of documenting that I pulled out the Ember-specific "Contextual Components" docs page into a more general "Glint Types" page that describes the user-facing types that@glint/template
exposes.There's some slightly broader reorganization of the docs that I think could be helpful, but I'll tackle that separately from this change.
Closes #412; fixes #410.