Details
-
Improvement
-
Resolution: Unresolved
-
Neutral
-
None
-
None
-
None
Description
Problem
Provisioning of the root sub-app view is not easy:
- as per logic of the UIComponent hierarchy the parent UI component needs to create its children.
- historically though, the BaseSubApp class (UIComponent now) requires its view to be injected directly in constructor
protected BaseSubApp(final SubAppContext subAppContext, final V view) - as a result - the root view of a sub-app cannot be a UIComponent itself. Neither we want them to be mapped types in the module (we no longer need to do that with views). As a result we typically end up declaring the root views as nested classes and pass a new instance into a super c-ctor.
- another example: in ContentBrowserSubApp we do declare the root view as UIComponent, but since we cannot automatically plug it into the hierarchy,
See e.g. i.m.ui.contentapp.ContentBrowserSubApp constructor calling super(subAppContext, new RootView());
The situation becomes even more confusing because of the SubApp#start method: it declares the sub-app view as return type and intuitively can be interreted as view factory. So far so good - I'd say this is aligned with the UIComponent hierarchy formation idea. But since the view is already injected in c-tor, we end up returning that injected instance from start().
Proposal
Do not require the root view to be injected into c-tor:
- refactor BaseSubApp? (might be not very backwards compatible, but could be done probably)
- deprecate and not use BaseSubApp at all? (there isn't much beef in it anyway, probably the content sub-app implementations can just directly implement the interface w/out the base class).
Checklists
Acceptance criteria