Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

perf(Scope): $apply isolation #5830

Open
kseamon opened this issue Jan 15, 2014 · 5 comments
Open

perf(Scope): $apply isolation #5830

kseamon opened this issue Jan 15, 2014 · 5 comments

Comments

@kseamon
Copy link
Contributor

kseamon commented Jan 15, 2014

Allow a new child (s) to be initialized in such a way as to limit calls to $apply made by
s and its decedents to $rootScope, s, and s's descendants.

This would be very beneficial to use-cases like dialogs where user interaction (And likely code) is isolated to a certain subtree of the page scope.

Inspiration is taken from the isolated-scope service employed by DCM which uses monkey patching to achieve this aim. It has made $apply calls in these isolated contexts substantially faster.

@bfricka
Copy link

bfricka commented Jan 21, 2014

Just curious, do you mean that this would be a default behavior of Scope or would it by an argument passed to Scope.$new?

@kseamon
Copy link
Contributor Author

kseamon commented Jan 21, 2014

It would be a non-default option, like isolate is today.

On Jan 21, 2014, at 3:35 AM, brian-frichette [email protected] wrote:

Just curious, do you mean that this would be a default behavior of Scope or would it by an argument passed to Scope.$new?


Reply to this email directly or view it on GitHub.

@g00fy-
Copy link

g00fy- commented Jan 22, 2014

@kseamon why not just use $digest ?

@kseamon
Copy link
Contributor Author

kseamon commented Jan 22, 2014

$digest is great when you're trying to digest the scope of your own directive. In this case, I'm talking about an isolated region of the page (It might be created by a directive, but it contains its own arbitrary markup and a controller).

In order to accomplish this behavior with just $digest, you'd need custom implementations of ng-click, input, etc that know to digest a particular scope instead of calling $apply as they do now.

@btford btford added this to the Backlog milestone Mar 27, 2014
@btford btford removed the gh: issue label Aug 20, 2014
@pjfsilva
Copy link

+1 exactly because of dialog windows: my app can have multiple dialogs open at one time and they don't need to interact with anything else, so I could really improve the performance isolating them with maybe an explicit way of communication

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

No branches or pull requests

5 participants