Skip to content
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

Merged
merged 7 commits into from
Aug 28, 2016
Merged

๐Ÿ˜ช Make view.childViews lazy #14139

merged 7 commits into from
Aug 28, 2016

Conversation

chancancode
Copy link
Member

@chancancode chancancode commented Aug 27, 2016

๐Ÿ†• getRootViews returns 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.

@chancancode
Copy link
Member Author

cc @teddyzeenny

}
},

class extends DescriptorTest {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indentation seems off here

@@ -188,7 +188,6 @@ class CurlyComponentManager {
aliasIdToElementId(args, props);

props.parentView = parentView;
props.renderer = parentView.renderer;
Copy link
Member Author

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?

Copy link
Member

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...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

๐Ÿ‘

Copy link
Member

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...

@homu
Copy link
Contributor

homu commented Aug 28, 2016

โ˜” 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.
@chancancode
Copy link
Member Author

Fixed the IE9 errors โ€“ they are due to IE9 not supporting strict mode

@chancancode
Copy link
Member Author

@chancancode
Copy link
Member Author

To be clear โ€“ the "confirmed no regression" means normal initial render performance, as opposed to .childView performance. It is expected that .childView will be slower, but since it's used for debugging we believe that is an acceptable tradeoff. This is better than the alternative where we have to pay the bookkeeping cost whenever we teardown a component during normal rendering.

@chancancode chancancode merged commit 8a49ddd into master Aug 28, 2016
@chancancode chancancode deleted the lazy-child-views branch August 28, 2016 07:41
},

linkChild(instance) {
if (!instance[OWNER]) {
if (!getOwner(instance)) {
setOwner(instance, getOwner(this));
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rwjblue @dgeb as a follow-up, do you think we still need this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, likely not needed.

@teddyzeenny
Copy link
Contributor

Shouldn't getRootViews and getChildViews be exposed on the ViewUtils object here?

@teddyzeenny
Copy link
Contributor

Updated in #14143

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants