-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
DO NOT MERGE: feat: reusable views #8184
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
base: main
Are you sure you want to change the base?
Conversation
Reusable views have to be teared down manually.
After further working on this, I'll also weigh in that I believe child views should not be destroyed even when detached simply because it's already the behavior on tabviews (which soft detaches elements) |
@edusperoni I'm curious what are your current thoughts on this PR? Does it still require changes? |
@NathanWalker I believe this just requires some testing and maybe treatment of edge cases. For example: if the view is detached and reusable is set to false, should it run _tearDownUI? Other than that, I think it'd be good as is. |
Flagging for 7.0 to test more with latest changes planned. |
8753605
to
86395da
Compare
d4ced42
to
53488b5
Compare
@edusperoni Let's update this to latest master either from a new branch or rebase. |
PR Checklist
What is the current behavior?
Views and view trees are destroyed when removed from the view tree.
What is the new behavior?
Views can be marked as
reusable
and will not be destroyed when removed from view tree. Removing these nodes require the developer to do:For implementation details on how frameworks should deal with it, see my work in
nativescript-angular
: https://github.com/edusperoni/nativescript-angular/tree/reusable-viewsImplements #7469.
To be defined:
What happens when a reusable view with children gets removed? The current implementation does not call _tearDownUI on children, but we should still suspendNativeUpdates down the chain (
this._suspendNativeUpdates(SuspendType.UISetup);
).Maybe we should we create a new SuspendType (Detached)? Maybe this isn't even needed as the view should be unloaded by
_removeViewCore
which eventually callsthis._suspendNativeUpdates(SuspendType.Loaded);
on all children.Possible refactoring needed (not directly related to this PR)
The current logic of
_resumeNativeUpdates
will callinitNativeView
. In most places I checked,initNativeView
creates delegates that are only removed indisposeNativeView
. This behavior is probably already an issue on loading/unloading views (like navigation) because ofthis._resumeNativeUpdates(SuspendType.Loaded);
, meaninginitNativeView
is called multiple times during the application lifecycle, but the delegates are only cleaned up once.During my tests with WebView, calling
initNativeView
did not result in a performance impact