Provide some means to generate from/toJson for compatible types for other code generators

[TekExplorer]

json serializable is a powerful generator. Often, other generators will want to be able to generate to/fromJson functions for its own use.

This can include retrofit, riverpod's v3 experimental @JsonPersist(), and plenty more, which are effectively forced to re-implement json_serializable, which will never be as good, and will always be missing features.

I noticed this issue when i tried using @JsonPersist() with a type that uses generic argument factories, and it failed to generate correct code. the same was true of Slugid, which does not have a fromJson constructor, and it does not have a toJson method. with jsonSerializable, i could tell json_serializable to use Slugid(json) and slugid.toString() as is proper, but attempting to support that in riverpod would be highly unreasonable, forcing me to wrap the class to use json_serializable on, which is bad API

Often, this can involve programatically supporting generic argument factories, enums, and even classes that dont directly support serialization, which could benefit from somehow applying @JsonKey and Converters

I'm not sure what the best way to do this is, but it would be a benefit if we could keep all serialization code centralized here

[kevmoo]

@TekExplorer – would you give some explicit, but simple code examples of the code you want to support and what you expect this package to generate for you?

[TekExplorer]

Sorry, i didnt realize i got a response. Here's an example:

@annotation
abstract class Foo {
  factory Foo() = _$Foo;

  Future<Bar> getBar(BarData data); // needs to know how to serialize BarData, and deserialize Bar

  // also examples like this;
  // what do we even do here?
  // i'd rather just pass the type and request generic argument factories - then using it is on me.
  Future<T> getUnknown<T>({required T Function(Object?) fromJson});
}
class _$Foo implements Foo {
  Bar getBar(BarData data) async {
    final serialized = serializeBarData(data); // this
    final response = await doSomething(serialized);
    final Bar bar = deserializeBar(response.data); // and this
  }
}

right now, it has to be done manually by whatever generator operates on @annotation but thats super inconvenient for the dev, who can only do basic support, which may or may not work with generics at all, not to mention special case classes like datetime.

Plus, if json serializable adds new support for new syntax in the future... we're kinda screwed. I'd expect to be able to pass @JsonKey() and @MySerializer() to either type like Future<@JsonKey() T> getBar(@BarDataSerializer() BarData data) (or putting it before the method - whatever) which my generator shouldnt need to know how to handle. i should be able to pass it blindly to JsonSerializable and receive a function that handles it.

http client generators are a good example - such as retrofit
so are state mangement like riverpod, which may want to know how to serialize the state type, but i cant just add @JsonSerializable() to that and call it a day, so we need some way to manually request it from our own generators