Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for nested master components #223

Closed
merryman opened this issue Mar 23, 2021 · 0 comments
Closed

Support for nested master components #223

merryman opened this issue Mar 23, 2021 · 0 comments
Assignees
Labels
✨ enhancement New feature or request

Comments

@merryman
Copy link
Member

(If this sounds confusing, thats fine. I just write this here so I dont forget this. Will clarify things later)

I feel like I am reinventing the wheel here, but I found the following quite helpful when working with master components and it is not yet (fully) supported by the system:
Especially when implementing UIs for Tools what you end up with is wanting to have several elements in a morph be derived from the same component and the ability to control which component that is. What you essentially want is a way to control the master component conveniently for a larger set of morphs. Basically something like a class. I think it is quite obvious what the master component way for such a thing is: Just as when working with prototypes, you want to use an "intermediate" master component which all these morphs are derived from and which we can then tell to derive from different master components, effectively altering the master component for that large set of morphs.
Now you can actually already build such a component composition and locally it works quite well.

Trouble starts however when we want to make use of this variability for different instances of such a component.
Let me explain on a concrete example: I ran into this when I wanted to build a slightly altered version of the styling side bar.
The styling sidebar contains a huge number of number fields which all derive from the same master component. So I went and popped an intermediate master component between to conveniently control the master component for all of these:
field_1 , field_2, .... field_n => intermediate_field => [dark_number_field | light_number_field]
Now when I created multiple copies of the side bar inside a world, there was however no convenient way to vary the appearance of all number fields for a side bar in isolation, since all of them still stuck to the same intermediate field.
So given side bars A and B, we had the following situation:
A.field_1 , A.field_2, .... A.field_n, B.field_1 , B.field_2, .... B.field_n => intermediate_field => [dark_number_field | light_number_field]
But what we actually want is more something like:
A.field_1 , A.field_2, .... A.field => A.intermediate_field => [dark_number_field | light_number_field]
B.field_1 , B.field_2, .... B.field_n => B.intermediate_field => [dark_number_field | light_number_field]

Essentially making this intermediate component a concrete part of an instance that is not shared across all derived morphs of a master component. Currently there is no good way of achieving that, and I am wondering what would be the best approach. Maybe support for "scoped" master components? By that I mean that certain components have the ability to define "sub master components" which are considered local to the component and not the world they are defined in.
Or thought of in the other way: The ability to define "own" master components is no longer restricted to the world but can basically be done by any other component in a scene, following the "turtles all the way down scheme".

Updating this when I had time to think more about this.

@merryman merryman added the ✨ enhancement New feature or request label Mar 23, 2021
@merryman merryman self-assigned this Mar 23, 2021
@merryman merryman changed the title Support for "class like" master component derivation Support for nested master components Apr 13, 2021
@LivelyKernel LivelyKernel locked and limited conversation to collaborators Nov 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
✨ enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant