Our current AppView and ViewContainer classes contain a lot of internal state that should not be part of the public API. Also, there is no central API for advanced users that want to work directly with Views and not with the DynamicComponentLoader.
I propose the following:
Add a AppViewManager with the following methods:
class AppViewManager {
createInPlaceHostView(parentComponentLocation:ElementRef, hostElementSelector, hostProtoView:AppProtoView, injector:Injector):AppViewRef {}
destroyInPlaceHostView(parentComponentLocation:ElementRef, hostViewRef:AppViewRef) {}
createDynamicComponentView(location:ElementRef, componentProtoView:AppProtoView, component:DirectiveMetadata, injector:Injector) { }
createViewInViewContainer(viewContainer:ElementRef, atIndex:number, protoView:AppProtoView, injector:Injector = null):AppViewRef {}
detachViewInViewContainer(viewContainer:ElementRef, atIndex:number):AppViewRef {}
insertViewInViewContainer(viewContainer:ElementRef, atIndex:number, view:AppViewRef) {}
destroyViewInViewContainer(viewContainer:ElementRef, atIndex:number) {}
clearViewContainer(viewContainer:ElementRef) {}
}
The class AppViewRef would reference an AppView, but also allows to make the reference invalid.
E.g.
class AppViewRef {
_delegate:AppView;
_valid:boolean;
}
Finally, we won't give the ViewContainer but a AppViewContainerRef to Viewport directives with the same API as the current ViewContainer and remove that API out of the current ViewContainer.
class AppViewContainerRef {
create(...)
remove(...)
...
}
This allows us to remove some fields out of the current ViewContainer (e.g. ViewFactory and ViewHydrator), which were needed as the current ViewContainer was not part of DI.
Note: On the renderer side we already have this structure in place, using the renderer itself as the view manager (see here.
Internal refactorings going along with adding a ViewManager (to be done also on the renderer side):
Move all recursion over views into the AppViewManager
- e.g.
ViewFactory.getView() should only create a single View but not recurse
- e.g.
ViewHydrator.hydrate... should only hydrate a single View but not recurse
--> Benefit: Unit tests become a lot simpler!
Our current
AppViewandViewContainerclasses contain a lot of internal state that should not be part of the public API. Also, there is no central API for advanced users that want to work directly with Views and not with theDynamicComponentLoader.I propose the following:
Add a
AppViewManagerwith the following methods:The class
AppViewRefwould reference anAppView, but also allows to make the reference invalid.E.g.
Finally, we won't give the
ViewContainerbut aAppViewContainerReftoViewportdirectives with the same API as the current ViewContainer and remove that API out of the currentViewContainer.This allows us to remove some fields out of the current
ViewContainer(e.g.ViewFactoryandViewHydrator), which were needed as the current ViewContainer was not part of DI.Note: On the renderer side we already have this structure in place, using the renderer itself as the view manager (see here.
Internal refactorings going along with adding a
ViewManager(to be done also on the renderer side):Move all recursion over views into the
AppViewManagerViewFactory.getView()should only create a single View but not recurseViewHydrator.hydrate...should only hydrate a single View but not recurse--> Benefit: Unit tests become a lot simpler!