[BUGFIX beta] Allow passing a string literal to {{helper}} and {{modifier}} #19487
Conversation
| // Bug: why do these fail? | ||
| // assert('[BUG] expecting a string literal for the `type` argument', isConstRef(typeRef)); | ||
| // assert('[BUG] expecting a string literal for the `loc` argument', isConstRef(locRef)); | ||
| // assert('[BUG] expecting a string literal for the `original` argument', isConstRef(originalRef)); |
There was a problem hiding this comment.
@pzuraq I don't think this has to block merging but it seems odd that we lost the const reference propagation here:
It seemed strange that isConstRef returned false on this. The logic in isConstRef checks for ref.tag === CONST_TAG but ref.tag is null here. Seems like a bug?
| import { internalHelper } from './internal-helper'; | ||
|
|
||
| export default internalHelper(({ positional }: CapturedArguments, owner: Owner | undefined) => { | ||
| // why is this allowed to be undefined in the first place? |
There was a problem hiding this comment.
@pzuraq This seemed strange. I suspect this is leftover from when you thought you didn't have to propagate owner in strict mode and left the | undefined in the signature, even though in practice it shouldn't ever be undefined?
|
|
||
| // BUG: this should work according to the RFC | ||
| // this.render( | ||
| // '[<div {{modifier "replace"}}>Nope</div>][<div {{modifier (modifier "replace") "wow"}}>Nope</div>]' |
There was a problem hiding this comment.
cc @pzuraq for upstream bug that we should fix before release (currently this gives an error message saying modifier keyword cannot be used as a modifier)
There was a problem hiding this comment.
| () => | ||
| this.render( | ||
| // BUG: this should work according to the RFC | ||
| // '<div {{modifier this.name}}>Nope</div>', |
chancancode
force-pushed
the
dynamic-helper-modifier-resolution
branch
4 times, most recently
from
fc0dba8 to
1b3960c
Compare
| // has to be included anyway. In the future, perhaps we can avoid the latter by using | ||
| // `import(...)`? | ||
| BUILTIN_KEYWORD_HELPERS['-disallow-dynamic-resolution'] = disallowDynamicResolution; | ||
| } |
There was a problem hiding this comment.
cc @rwjblue though it probably doesn't have to block merging
There was a problem hiding this comment.
Ya we should fix, I agree. But it doesn't really matter for landing.
chancancode
force-pushed
the
dynamic-helper-modifier-resolution
branch
from
1b3960c to
80d052c
Compare
| // has to be included anyway. In the future, perhaps we can avoid the latter by using | ||
| // `import(...)`? | ||
| BUILTIN_KEYWORD_HELPERS['-disallow-dynamic-resolution'] = disallowDynamicResolution; | ||
| } |
There was a problem hiding this comment.
Ya we should fix, I agree. But it doesn't really matter for landing.
chancancode
force-pushed
the
dynamic-helper-modifier-resolution
branch
from
80d052c to
d483598
Compare
…fier}} As per [RFC #432](https://github.com/emberjs/rfcs/blob/master/text/0432-contextual-helpers.md#invoking-contextual-modifiers) However, dynamic string values are currently disallowed per earlier framework team weekly meeting discussion to not make it harder for Embroider to heuristically analyze the dynamic usages. Eventually we will want to do the same for components as well, and this AST transform would work there too.
chancancode
force-pushed
the
dynamic-helper-modifier-resolution
branch
from
d483598 to
397d6b9
Compare
As per RFC #432
However, dynamic string values are currently disallowed per earlier framework team weekly meeting discussion to not make it harder for Embroider to heuristically analyze the dynamic usages.
Eventually we will want to do the same for components as well, and this AST transform would work there too.