Closed UkoeHB closed 3 months ago
This makes sense
On second thought this makes less sense to me. spawn
for the UiRoot
version means 'create self', while spawn for
Entity` version means 'create child'.
On second thought this makes less sense to me.
spawn
for theUiRoot
version means 'create self', whilespawn for
Entity` version means 'create child'.
The reason I had the double implementation is because there aren't many elements that support being a Root element. Basically rows and columns. The current version would let us create a widget with a different setup if they are root elements. Not sure how useful it is, but let's keep it as it is now and revisit later when there are more use-cases
I added a style-loading-from-file extension to UiBuilder
that returns the current node. The value returned is a bit different if you have a root vs normal entity in the builder.
I could just not return anything from these methods, but it's an example where the behavior could be dependent on the builder type.
Another, albeit crude example would be that a root-spawn could insert the default theme automatically. Or we could have an extension only on the UiRoot that does that (i.e. ui_builder.themed_root(...)
Let's keep it as-is. If we run into an issue where it becomes too much to maintain the two, we can revisit then. Cheers.
I recommend moving the
spawn
method fromUiBuilder
to a trait implemented by bothUiRoot
andEntity
variants. Then you only need a single impl for extension traits, using theT: UiSpawner
trait bound.