Exposing multiple child-roots from a scene

[roookeee]

Description

It is currently very hard to make reusable scenes whichs' main purpose is to provide a reusable (child) structure with some common logic (most often UI related).
Imagine the following scene you want to reuse:

It's a custom Window scene whichs own script is just handling the closing via the X button in the header (this is simplified).
This Window scene has three content areas:

• the header
• the (optional) pre-tab content
• an unspecified amount of tabs which varying content

I would like to have a system which allows me to add different children in different content areas (see the image above). I tried the following approaches which have undesired outcomes / consequences:

• programatically re-rooting added children to the desired internal location via a [Tool] script, this breaks all editor support (e.g can't click ui elements anymore) and loses data
• programatically re-rooting added children by a copy that is maintained by the script. This is fragile and a lot of work to keep synced without data loss.
• all code-side solutions suffer from "magic ordering" or "magic names" to know where to to re-root each added child, which is non-ideal to say the least
• using Editable children and adding children to the desired internal scene location. This is too easy to screw up and silently looses data when the Window scene changes its internal structure. It also undermines the purpose of reusable scenes to force all usages to restructure themselves whenever the reusable scene changes its internal structure instead of working automatically
• overriding add_child in a GDScript which is probably unintended to be possible as its non-virtual in C++ and not overridable in C#

These issues provide the baseline requirements for such a system:

• have full editor support (including correct targeting via clicking a desired element)
• does not lose data when a "content root" changes position or is exchanged with another element
• does not limit the type of content that is output (e.g. why not output 15 LineEdits in the header area?)
• editing such a reusable scene instantly applies to all its usages without breaking apart when no breaking-change happens (breaking change = removal of a content root, not updating it to another node)

Idea

Instead of implicitly exporting one content root for all children provide a way to [Export] multiple content roots from a scene. These content roots are pseudo-elements which hold onto their children and add their children to the current value of the [Export]ed Control (I don't know if this system would be desirable for non-UI elements).
These pseudo-elements would only loose data when they are deleted, which is easily avoidable. Re-assigning these pseudo-elements actual nodes would just re-root them internally, which should be easy to achieve - all in all this is just an indirection.

As far as I am aware this is currently impossible to implement on the user-side but my knowledge of Godot is very limited.
I am open for any other way or even fixing this outside the engine core but asking on reddit / the Godot forums yielded nothing.

We are currently copy&pasting these layouts as we found no desirable way to solve this issue. This will probably create issues in the future as we will probably reiterate and restructure every single window internally to e.g. get an updated styling / behavior / structure which needs to be consistent across the board.

This idea has usages outside of multiple "content roots" as well e.g. when you only have one "content root" which is not the scenes root node e.g. you want to add your children to a margin container inside your root node, not as a sibling.

P.S: Thank you for your hard work <3

[roookeee]

Ping, any feedback is appreciated. I am still hoping that someone with more experience in Godot could chime in and offer a (partial) solution or different workflow to avoid the mentioned repetition and its flaws. No need to add something as complex as I propose if the whole workflow is flawed or is possible without adjustments.

[1998marcom]

I stumbled across the same problem recently, and I miss the reusability of containers/components of other frameworks, like React/JSX. If you want, you can have reusable containers if you resort to writing them with GDScript instead of making them with the WYSIWYG Godot editor.

You might also be interested in checking out this proposal discussion I opened to get a more JSX-like syntax for writing components in script.

[Zireael07]

Reusable scenes with child structures are still an issue. My workaround is to put everything up to the root node as exported variables but this then requires carefully sending info back down the tree.