refactor: Component's lifecycle futures moved into LifecycleManager

[st-pasha]

Description

Small refactor (which was proposed a long time ago) that moves Component's properties ._loadCompleter and ._mountCompleter into the _LifecycleManager class without changing the user-facing API. The purpose of the move is to de-clutter the Component's namespace.

Checklist

• The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
• I have read the Contributor Guide and followed the process outlined for submitting PRs.
• [-] I have updated/added tests for ALL new/updated/fixed functionality.
• [-] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• [-] I have updated/added relevant examples in examples.

Breaking Change

• [-] Yes, this is a breaking change.
• No, this is not a breaking change.

Related Issues

Closes #1426

[erickzanardo]

Tbh, I don't see much value on this change, we just moved the attributes to the LifecycleManager but the logic is still on Component.

I would rather keep them together unless we can figure it out a way to keep both things together.

[wolfenrain]

Tbh, I don't see much value on this change, we just moved the attributes to the LifecycleManager but the logic is still on Component.

I would rather keep them together unless we can figure it out a way to keep both things together.

Apart from this I am also curious if this comes with added benefits in the area of reusability in some places? Or is just purely a "clean-up" PR? I am fine with either the original code or this. Just wondering if this has extra benefits in the long run as well

[st-pasha]

The idea here is that both loadCompleter and mountCompleter are futures that are (1) rarely needed by the user, (2) even when used, are only valid for a very brief period of time - few milliseconds at the beginning of the component's lifecycle. By moving these into the LifecycleManager class, we ensure that:

• the size of the Component class is now smaller;
• debugging is now easier because there are fewer properties in the Component class in a debug window.

Given that Component is the base class for ALL other components, I believe it's best to keep the class as lean as possible.

[erickzanardo]

the size of the Component class is now smaller;

That isn't true, they completers were already optional, so the footprint don't change, unless you are mentioned size as in line numbers, but if so, that difference is minimal and not worth having the attribute on a place and the logic in another.

debugging is now easier because there are fewer properties in the Component class in a debug window.

Same as I mentioned above, IMO that difference is minimal and not worth having the attribute on a place and the logic in another.

[st-pasha]

That isn't true, they completers were already optional, so the footprint don't change

Even if a variable is null, it still takes up some space inside the class, since that null pointer needs to be stored somewhere.

not worth having the attribute on a place and the logic in another.

The LifecycleManager is a Component's appendix; it's specifically designed to hold optional/temporary parts of the Component that can be discarded once there is no need for them anymore. This is exactly what loadCompleter and mountCompleter are. For these fields, the LifecycleManager is a more natural place than the main Component.

[erickzanardo]

For these fields, the LifecycleManager is a more natural place than the main Component.

This I agree! But for me, none of these are worth the drawback of having the fields on a class, while they are managed on a different place.

If we can find a way to move the logic of loaded and mounted to the LifecycleManager, while keep the API without a breaking change, I am onboard. Otherwise I prefer to keep the field and the logic together.

[st-pasha]

If we can find a way to move the logic of loaded and mounted to the LifecycleManager, while keep the API without a breaking change, I am onboard. Otherwise I prefer to keep the field and the logic together.

Hmm, I see your point. I'll try to think of something that can be done along these lines.