Conversation
This will break a lot of things but is a good excuse to rethink the "process args" code.
|
☔ The latest upstream changes (presumably #15247) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (presumably #15254) made this pull request unmergeable. Please resolve the merge conflicts. |
This is only needed when a catastrophic failure happens that prevents the normal removal from working. Doing this in the teardown greatly reduces the number of invalid faulures when errors occur during rendering.
These are largely duplication functionality in `{{each-in}}`'s own
tests. They were added as a way to flesh out the iterable implementation.
|
Interesting seeing the dog fooding of component-managers and how they are used. Good stuff and much to learn. |
…PathReference` API.
Fixes a few node tests.
|
Did some quick asset size checks, and the |
|
I did some general benchmarking (against the emberaddons.com app), and it seems that we haven't introduced a regression here.
Seems good to ship... |
|
|
|
Did another test against emberobserver.com (which has a larger rendering phase):
|
| } | ||
| } | ||
|
|
||
| didCreateElement() {} |
There was a problem hiding this comment.
Can't these go on the abstract manager?
| return null; | ||
| } | ||
|
|
||
| didCreateElement() {} |
There was a problem hiding this comment.
Same comment about putting them on the abstract manager.
|
LGTM |
|
Woop |
5 participants
ember-glimmer/utils/iterable#14763 (comment))