refact: proposal for a new design arround component tree

[FabienArcellier]

This is a refactoring proposal to make the notion of component tree simpler. This refactoring removes the 3 distinct classes that inherit from each other to represent the 3 trees. It removes cascading inheritance and method overloading.

There is a single class ComponentTree class that can combine fragments. One fragment for BMC, one for CMC, one for SMC. A fragment can be frozen to lock its contents. Fragments are an instance of the same ComponentTreeFragment class.

The application contains 2 tree construction methods. build_base_component_tree which builds the tree the application needs upon loading with a fragment for BMCs and CMCs. build_session_component_tree builds a tree dedicated to the user session with 3 fragments, one fragment for SMCs, one for CMCs and a frozen fragment for BMCs. The fragments are copied to separate them from the base representation.

I added in the tests, 2 distinct contexts, one to represent a ui manager when streamsync application is loading and one to represent a ui manager in an event handler.

[ramedina86]

This is a step in the right direction. However, I'd like to change the nomenclature "smc" as I don't think it's reflective of what we're doing.

Manage should be interpreted in the sense of enabling the user to create, delete, etc. Not from an internal perspective. Two categories emerge:

• Builder-managed
• Code-managed

The other classification emerges from the specificity of the components:

• Shared/base
• Session-specific

Therefore, the combinations are:

• Builder-managed base components
• Code-managed base components
• Builder-managed session-specific components
• Code-managed session-specific components

There are currently no plans to have builder-managed session-specific components. For simplicity, we can adopt the following:

• Builder-managed base components: bmc
• Code-managed base components: cmc
• Code-managed session-specific components: session-cmc

@mmikita95 fyi, feel free to add to the conversation

[FabienArcellier]

This is a step in the right direction. However, I'd like to change the nomenclature "smc" as I don't think it's reflective of what we're doing.

That's sound interesting, I will take a look at the change involved.

[mmikita95]

@ramedina86 great breakdown, thank you!

One thing I would probably adjust is to shift focus on "session CMCs" as "main CMCs" (i.e., use names like "pre-session CMCs vs session CMCs or in-session CMCs"), because in my opinion, while "pre-session CMCs" are expected to be used more widely, technically the session context is the last point that collects all components into a "render package", and one can view "pre-session CMCs" as "copies made for the session". Therefore, to better reflect this technicality, I'd suggest this naming convention. Sorry if this is turning out to be too confusing 😅

[ramedina86]

Excellent point @mmikita95 , glad I tagged you. With this in mind, what classification (short names) would you go for?

[mmikita95]

My thought is

• Builder-managed components (bmc)
• Pre-Session code-managed components (pscmc)
• In-Session code-managed components (iscmc)

but I'm slightly dubious on that, as these 5-letter acronyms look dangerously "too much".

[ramedina86]

iscmc sounds too much like a boolean. The pre is slightly confusing to me. How about:

• bmc
• initial_cmc
• session_cmc

in line with state (initial_state, session_state).