Generate sealed classes without of using freezed

[Tienisto]

Is your feature request related to a problem? Please describe. When using enum sum types in Rust like

pub enum HttpBody {
    Text(String),
    Bytes(Vec<u8>),
    BytesStream,
    Form(HashMap<String, String>),
    Multipart(MultipartPayload),
}

Then FRB generates

@freezed
sealed class HttpBody with _$HttpBody {
  const HttpBody._();

  const factory HttpBody.text(
    String field0,
  ) = HttpBody_Text;
  const factory HttpBody.bytes(
    Uint8List field0,
  ) = HttpBody_Bytes;
  const factory HttpBody.bytesStream() = HttpBody_BytesStream;
  const factory HttpBody.form(
    Map<String, String> field0,
  ) = HttpBody_Form;
  const factory HttpBody.multipart(
    MultipartPayload field0,
  ) = HttpBody_Multipart;
}

However, since Dart 3.0 is supported, we can remove the freezed annotation and generate the classes ourself:

sealed class HttpBody {
  const HttpBody();

  const factory HttpBody.text(String field0) = HttpBodyText._;
  const factory HttpBody.json(Map<String, dynamic> field0) = HttpBodyJson._;
  const factory HttpBody.bytes(Uint8List field0) = HttpBodyBytes._;
  const factory HttpBody.stream() = HttpBodyBytesStream._;
  const factory HttpBody.form(Map<String, String> field0) = HttpBodyForm._;
  factory HttpBody.multipart(Map<String, MultipartItem> field0) =
      HttpBodyMultipart.map;
}

class HttpBodyText extends HttpBody {
  final String text;

  const HttpBodyText._(this.text);

  // hashCode, ==
}

class HttpBodyJson extends HttpBody {
  final Map<String, dynamic> json;

  const HttpBodyJson._(this.json);

  // hashCode, ==
}

This is useful to minimize the amount of dependencies if freezed is never used elsewhere.

Describe the solution you'd like Add option to use sealed classes instead of freezed for enum sum types.

Describe alternatives you've considered None.

Additional context For https://github.com/Tienisto/rhttp

[fzyzcjy]

Looks reasonable and feel free to PR for this! Alternatively, I may work on it later but may not be top priority, since it is not a bug and has workaround (i.e. introducing the freezed dependency which is a super popular package).

A workaround before it is implemented: Maybe you can firstly introduce freezed dependency and generate the code, and then copy-paste or modify the code, such that the freezed dependency is removed (should not be too hard since that runtime package seems only contain some utility).

[fzyzcjy]

Btw checked https://pub.dev/packages/rhttp and seems it depends on freezed_annotation, which looks like quite lightweight and high-quality (https://pub.dev/packages/freezed is an official Flutter Favorite package).

Another thing may be, we may also ask on the freezed repo about whether the dependency can be eliminated. That seems to be more general purposed (if it is done, every lib using freezed will reduce dependency) than the current proposal (if it is done, only lib using frb+freezed will reduce dependency)