ember-render-modifiers
ember-render-modifiers copied to clipboard
emberjs
Modifiers don't seem to work when applied to elements are ember components with `tagName=''`
Using modifiers on an element that is itself a classic Ember component (@ember/component) doesn't seem to work.
This poses difficulties because the developer now has to 'know' :godmode: what the
other component is.
This works great:
<div {{did-insert this.someFunc}}>
</div>
This not so much (doesn't error, doesn't execute).
<SomeOtherEmberComponent {{did-insert this.someFunc}}>
</SomeOtherEmberComponent>
Apologies - I updated the name and content of the first comment - I misspoke on glimmer vs. ember. Issue is correct now.
Further update - some more testing reveals that the issue only occurs when the target component has tagName='' - we can work around this by converting those components to @glimmer/component as well, but not where we don't own them (add-ons, etc.).
Confirm, when using tagName: '' there is no element to modify. Arguably, this should error (just like it would error if you specified attributeBindings or click on that component), but I'm not exactly sure how we'd do that.
As the issue unfolds here a little further, it's worth mentioning that the parent glimmer component (GC) needs to use the did-update modifier, not to alter the element, but to detect changes on an incoming attribute on the GC. Not the intended use of a modifier, but not sure GCs offer any other way to do so - thinking an EC task with waitForProperty and a callback, and having it perform itself as a tail call, but that's really just an observer hack.
Any thoughts?
I'm doing some issue gardening 🌱🌿 🌷 and came upon this issue. Since it's quite old I just wanted to ask if this is still relevant? If it isn't, maybe we can close this issue!
By closing some old issues we reduce the list of open issues to a more manageable set.
This is covered by https://github.com/machty/emblem.js/issues/340 but is still an issue - the fundamental point being that modifiers don't work "as one might intuitively expect at first glance" when used on components - if #340 is solved, I think this would cease to be a problem.