Layers of abstraction are hard to implement #6021
Description
What were you trying to do?
Once a project reaches a certain amount of complexity you need to split it into easily understood pieces.
Those pieces may furthermore be composed out of smaller parts. (and so on)
What have you tried to achieve the task?
Duplicating and configuring premade objects within the inspector is one way to approach this.
Additional tooling is available if the templates should be placed within the 3D space of a world.
ProtoFlux can be used to automate instantiation of the templates based on user-defined information.
Some people offer snippets or whole systems (i.e. partial JSON parsers) you can integrate into your own ProtoFlux.
Reducing duplication of ProtoFlux requires moving code to "manager systems" using dynamic impulses on the large scale and e.g. demultiplexer/multiplexer constructs within individual ProtoFlux groups.
What did you get stuck on or what was difficult?
Manual duplication has the unfortunate side-effect that your creation becomes more or less "write-once".
Any changes to the templates require you to manually update all instances of them.
Some user-made tools provide workflows to update templates but this depends on the tool in question. It also ties the features "object placement" and "template management" together.
Custom ProtoFlux-based template instantiation needs a lot of set up. (How do you find instance definitions? How do you configure options? ...)
All phases of an instance's life-cycle need to be implemented manually. (kind of reinventing the wheel...)
Creating a reusable template-instantiation system adds even more development overhead.
When it comes to reusing other people's creations it becomes really hard because the moment you integrate them into your own it may be outdated or needs to be hardcoded into. (i.e. ProtoFlux templates)
It can distract from the problem to be solved when one adds multiplexed logic for the sake of reusing a piece of code.
Dynamic Impulses are not a full replacement for methods/functions/modules.
Working with UIX in general requires you to work a lot at the low level of individual UIX components.
While it is nice to be able to compose unique UI designs out of simple components it becomes quite repetitive (and hard to refactor e.g. the styling).
What parts (if any) of the process were easy and worked well?
The early/prototyping phase when a project is small works well. This makes it even harder for custom-made template instantiating systems because the switch away from manual duplication. (feels much costlier)
A solution to the mentioned problems would need to be low effort to compete with the "lazy" way.
A few dynamic variable based interfaces that broadcast colors or similar information into the world are quite successful. -> Not all reuse needs complex code or systems.
Screenshots / Video
The following object contains a mix of dynamically instantiated templates (table contents) and manually duplicated and modified elements (buttons):
Adding a tooltip feature to all UI elements required a lot of manual modification. Developing a system that is able to upgrade all of them while preserving the individual configuration was not considered worth the effort at the time it would have been most efficient to do so. (very early)
If a solution to the problem was low-effort maybe this would not have happened.
Related bugs / feature requests
#6016 has breached a lot of topics so there is some overlap in the context of "template instantiation" but I see it not from the perspective of a specific editing workflow but more the general idea of "building things made up of smaller things".
Reporters
The report mostly comes from me. (@mpmxyz)
I also know that a bunch of work from @JackTheFoxOtter involved template instantiation for games.
I think Businesslawyer has also created tools involving template instantiation with template upgrade features. (and many others likely do)
Many ProtoFlux prints (e.g. from @ukilop or @ColinTimBarndt) use manager systems to offload ProtoFlux out of print instances. They likely invented their own calling conventions to get more out of dynamic impulses.