Native support for Adventure API Component

[zvyap]

It would be beneficial for this library to include native support for commonly used Adventure API objects such as TextComponent, Sound, and Key.

In my experience, I've used this library in two different projects, and the first task I always undertake is copying the ComponentSerializer, SoundSerializer, and KeySerializer modules.

The Adventure API also provides support, some of which is even native on other platforms. It would be advantageous to integrate similar support into this library. You can find more information about Adventure API support on other platforms here: https://docs.advntr.dev/platform/native.html

[Exlll]

Hi, thanks for your suggestion!

To get support for these additional serializers, you'll probably have to use a custom ConfigurationProperties object (similar to what you already have to do currently to get support for Bukkit's ConfigurationSerializable), i.e.:

YamlConfigurationProperties properties = ConfigLib.PAPER_DEFAULT_PROPERTIES.toBuilder()
     // ...further configure the builder...
    .build();

 // ...use builder to save/load configurations

What do you think about this approach? Perhaps you have a different idea in mind?

I've used this library in two different projects, and the first task I always undertake is copying the ComponentSerializer, SoundSerializer, and KeySerializer modules.

Could you perhaps share the relevant parts of your code/config to give me an idea of how you currently do it?

[zvyap]

Hi, thanks for your suggestion!

To get support for these additional serializers, you'll probably have to use a custom ConfigurationProperties object (similar to what you already have to do currently to get support for Bukkit's ConfigurationSerializable), i.e.:

YamlConfigurationProperties properties = ConfigLib.PAPER_DEFAULT_PROPERTIES.toBuilder()
     // ...further configure the builder...
    .build();

 // ...use builder to save/load configurations

What do you think about this approach? Perhaps you have a different idea in mind?

I think you should change the way that add support to a platform. Currently, we are using ConfigLib.PAPER_DEFAULT_PROPERTIES to add support to paper/bukkit stuff, but Adventure API is supported in various platform.

How about using this way to add specify support to a platform

ConfigLib.newBuilder()
      .addBundle(ConfigLibBundles.PAPER)
      .addBundle(ConfigLibBundles.ADVENTURE_API)

I've used this library in two different projects, and the first task I always undertake is copying the ComponentSerializer, SoundSerializer, and KeySerializer modules.

Could you perhaps share your the relevant parts of your code/config do give me an idea of how you currently do it?

I just make my own class that implements Serializer<Component, String>, nothing special
For sound, I deserialize string format "<sound_id>:[pitch]:[volume]:[source]"
For component, I just deserialize String with https://docs.advntr.dev/serializer/index.html.
For Key, just deserialize string to Key object, nothing special.

[typicalsmc]

odd question, do the deserialize and serialize progress only do once ? like when i want to get the Component, do ConfigLig call adventure api to deserialize it everytime i get the Component or it just return the cached one ? from what i have tested, that progress cost some performance if it just spam call it

[Exlll]

ConfigLib doesn't cache values. Only the serializers are "cached", i.e. the (recursive) decision which serializer to use for which field is only made once at the beginning when the YamlConfigurationStore is initialized. However, if you use the static methods in the YamlConfigurations class (instead of initializing a YamlConfigurationStore and using its methods), you don't benefit from this caching either since each of these static methods creates a new store at every invocation. (Note that this optimization doesn't apply to @Polymorphic types.)

Does this answer your question?

[typicalsmc]

yea, i understand it, im moving to use YamlConfigurationStore now then