@kezz right now the virtual component is treated as/turns into a text component whenever its serialized -- when we get a public custom serializer API on MM we will have to make sure user-provided serializers can claim virtual components before the built-in serializers get a say.

After fiddling around with this a bit to use the API in MM, I think this will need some more iteration before it's ready to push out.

Some key things:

• equality and examinableness of virtual holders
• ensuring api operations preserve virtual components where possible
• thinking about the level of boiler plate needed to create data -- do we need the two-layer system?

thinking about the level of boiler plate needed to create data -- do we need the two-layer system?

Would it make sense to, instead of having the 2-layer VirtualComponent -> VirtualComponentHolder<?> -> boxed data, as well as the need for a custom renderer, have the component itself have a "virtual component renderer" instead?

A way to do that would be to make it so VirtualComponent internally has a Function<C, Component> (or functionally equivalent VirtualComponentRenderer) which is used at render time to get the actual component, replacing the current unbox. Such function is part of 3rd party plugins and so they can have as much state or non-state as they want within it, and adventure doesn't really need to care about it. This essentially shifts the focus of the "virtual component holder" so instead of "holding data" it's the "how does this get rendered"

An example of a simple component which would show each player their own name:
virtual(context -> text(context.getOrDefault(Identity.NAME, "no name :(")));

Main issue I see (correct me if i'm wrong) is context is generic in adventure, and only in platform does it get a specific type, so one platform may use pointered and others may use something else? i have not looked into that one.

equality and examinableness of virtual holders

I think that just goes out the window, simply because it no longer becomes adventure's territory, it's a "whatever that 3rd party plugin decided" territory. How relevant is it to adventure how internally the renderer of the 3rd party plugin decides to be? Do equal-ness checks break adventure in significant ways if they're not respected for the renderer of virtual components?

Hey, any updates on this? It'd be great to see the functionality finally landing on adventure

I would like it if you could add a builder wrapper for use with the virtual component system.
In our project we create and use custom components. Having the ability to build on top of the virtual component system would be very helpful and would help reduce the current amount of hackery we do.

Currently the abstract builders are private (for good reasons). However we are willing to deal with breaking changes when needed, the virtual components however would solve this ongoing issue and prevent any more breaking changes from affecting us.