Type-Safe Placeholders/Templating with ValueSerialiser integration

[gepron1x]

My idea is about utilizing method arguments as ValueSerializer parameters. With them, we can pass some context to the serializer when we are getting the value. Ill give an example:
Lets assume that we have a config with Component message that has sender placeholder:
public interface TestConfig { Component message(@Argument("sender") Component sender); }
And in value serializer, we pass arguments in the map where key is arg name/string defined in @argument, and Value is argument value.
public Component deserialise(FlexibleType value, Map<String, Object> args) throws BadValueException { List<Template> templates = args.entrySet().stream() .map(entry -> Template.of(entry.getKey(), (Component) entry.getValue()) ).toList(); return miniMessage.parse(value.getString(), templates); }
I think this addition would make code much cleaner in some cases, especially if you have placeholders in your message.
But, to be honest, im not sure if its the best solution.

[A248]

This feature needs careful consideration. It would very much improve consumer code; in fact, remembering to replace placeholders is now the most error-prone part of my own code. One of this library's most important original goals was to reduce bugs arising from mis-typed configuration keys such as config.get("my-config-option-with-a-typo"). Perhaps the next step in its evolution is to tackle placeholders, which are similarly frequently-used yet liable to mistake.

Nevertheless, a feature like this would be a significant step in this library's purpose. It would transform DazzleConf into more than a type-safe boilerplate-minimal configuration library. This carries associated costs. It introduces additional complexity into a small and easily-maintained library.

For the purpose of discussion, I'll tentatively tack this on to the 2.0.0 milestone. I'd very much like to hear what other users have to say and what extra solutions they employ, if any, with respect to templating.

[ghost]

i like the idea, seems to be suuuper useful! type-safe placeholders is what i need.

[A248]

If we implement this feature, I am thinking it will follow this two-step process:

1. The configuration value is loaded with DazzleConf into its required type. This is what happens normally, without placeholders. It is DazzleConf's main purpose to perform this upfront, fail-fast configuration loading.
2. Later, when the configuration method is invoked, placeholders are replaced.

This process has implications for the example you posted, @gepron1x . It means that MiniMessage must have a good way to replace templates in an existing Component. The reason is that DazzleConf first needs to load the Component using the standard mechanism in order to provide fail-fast behavior. Later, when the method is called, placeholders are replaced. Such operation is also more efficient than parsing the entire MiniMessage string every time the method is called.

Note that this idea can exist in tandem with #20 , if both are implemented, by using method overloads.

[gepron1x]

Well, adventure developers are not really a fan of replacing in existing Components. Component is treated as a "compiled" piece of text which ideally shouldnt be changed internally.

In adventure's case i just made an utility class Message(String value, MiniMessage miniMessage) which implements ComponentLike where you can set placeholder first and then construct a component to use.
I do not see any problems