Having business logic to be structured in one place, and loading it with the typed entity repository mechanic, is a huge DX improvement.
Also for a very common topic, which is rendering something, we have an explicit Renderers component.
Another involved aspect in such a common topic is the involved fields. As mostly something is being rendered based on some data, which is mostly stored in a (configured) field.
It kinda feels that the definition of such fields, or at least a way of dependency resolving to them, could be something that Typed Entity is also doing. It could ensure the availability of fields and therefore ensure that a key component is available (like a check of prerequisites).
Not sure yet what could be a viable solution path. Since Typed Entity is something that addresses code-based implementations, not configuration, I think it cannot be just thought of what config dependencies do in the configuration management system.
There is the ability to define base fields (via code), and AFAIK also the possibility to define bundle fields via code. Maybe Typed Entity could also offer a definition of fields that are being made available. However this is not that easy as one could reuse fields accross multiple typed entity repository plugins.
This was just an idea that came to my mind and thought it's worth to write it down here. I've looked into other existing issues, some of them already address the field topic, but am not sure whether they mean the same thing. Feel free to close this one as duplicate of another / or won't fix of course when this topic is not relevant at all.
Active
4.0
Miscellaneous