[MGNLUI-5920] Remove View argument from constructor that's created within subapp Created: 04/Jun/20  Updated: 15/Oct/20

Status: Open
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Šimon Demočko Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: ui-devx-impr
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)

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

Generated at Mon Feb 12 09:31:22 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.