-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
๐ช Make view.childViews
lazy
#14139
Conversation
cc @teddyzeenny |
3e2f1a3
to
5426dcb
Compare
} | ||
}, | ||
|
||
class extends DescriptorTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indentation seems off here
5426dcb
to
e737292
Compare
@@ -188,7 +188,6 @@ class CurlyComponentManager { | |||
aliasIdToElementId(args, props); | |||
|
|||
props.parentView = parentView; | |||
props.renderer = parentView.renderer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The last failure is because I removed this code. It seems like engine components are not getting these injections setup: https://github.com/emberjs/ember.js/blob/master/packages/ember-application/lib/system/application-instance.js#L291-L297 (maybe the rest of things in that block too?)
I can add this back, but it seems better to just fix the injection. @rwjblue @dgeb can you halp?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya, I can fix. Might be easier to put it back for now and I'll fix with a follow up PR later this afternoon...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
๐
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tackled this in #14140 (which has caused you yet another rebase conflict). Sorry...
e737292
to
52edd7a
Compare
โ The latest upstream changes (presumably #14140) made this pull request unmergeable. Please resolve the merge conflicts. |
This is dead code, we donโt actually call these methods anywhere in the codebase anymore.
We also donโt need to propagate `parentView` in `linkChild` anymore: since 9228bb8, `parentView` is supplied via the โcreate propsโ for both engines to ensure that it is available during `init`.
๐ `getRootViews` return an array of โtop-levelโ components ๐ `getChildViews` to replace `view.childViews` (to be deprecated ๐) ๐ โtaglessโ components are registered in the view-registry with a GUID ๐ `view.childViews` is now a getter that delegates to `getChildViews` ๐ `view.childViews` no longer leak destroyed components (bug in beta) ๐ `view.childViews` now tracks updates (components added or removed during updates) correctly, which was unreliable since 1.13 Instead of tracking `childView` instances, we now track a list of IDs that can be used to look them up in the view registry. This has the benefit of not holding a reference to the view instance โ thus do not require cleanup when the child views are destroyed. When requested, we lazily query the view registry to reify the (still) live children and cleanup and stale IDs while we are at it. This approach does leak the string IDs of destroyed components, however the effect is believed to be minimal. If this ended up causing problems, we can be smarter about this, such as tracking the number of removals and schedule a collection (outside of the render loop) when a view has accumulated enough removals.
52edd7a
to
4e5ddae
Compare
f95c9c9
to
8f3c5b5
Compare
Fixed the IE9 errors โ they are due to IE9 not supporting strict mode |
To be clear โ the "confirmed no regression" means normal initial render performance, as opposed to |
}, | ||
|
||
linkChild(instance) { | ||
if (!instance[OWNER]) { | ||
if (!getOwner(instance)) { | ||
setOwner(instance, getOwner(this)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, likely not needed.
Shouldn't |
Updated in #14143 |
๐
getRootViews
returns an array of โtop-levelโ components๐
getChildViews
to replaceview.childViews
(to be deprecated ๐)๐ โtaglessโ components are registered in the view-registry with a GUID
๐
view.childViews
is now a getter that delegates togetChildViews
๐
view.childViews
no longer leak destroyed components (bug in beta)๐
view.childViews
now tracks updates (components added or removed during updates) correctly, which was unreliable since 1.13Instead of tracking
childView
instances, we now track a list of IDs that can be used to look them up in the view registry. This has the benefit of not holding a reference to the view instance โ thus do not require cleanup when the child views are destroyed.When requested, we lazily query the view registry to reify the (still) live children and cleanup and stale IDs while we are at it.
This approach does leak the string IDs of destroyed components, however the effect is believed to be minimal. If this ended up causing problems, we can be smarter about this, such as tracking the number of removals and schedule a collection (outside of the render loop) when a view has accumulated enough removals.