How to use with freezed unions?

[MiniSuperDev]

Hello,, when use freezed it generate only private classes and also expect other type in the model, for example instead of Union1 it expect _$Union1

Thank you

import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:reactive_forms_annotations/reactive_forms_annotations.dart';

part 'freezed_union.freezed.dart';
part 'freezed_union.g.dart';
part 'freezed_union.gform.dart';

@freezed
class FreezedUnion with _$FreezedUnion {
  @ReactiveFormAnnotation()
  const factory FreezedUnion.union1({
    @FormControlAnnotation() required String text,
  }) = Union1;

  @ReactiveFormAnnotation()
  const factory FreezedUnion.union2({
    @FormControlAnnotation() required int number,
  }) = Union2;

  factory FreezedUnion.fromJson(Map<String, dynamic> json) =>
      _$FreezedUnionFromJson(json);
}

void main() {
  final form = _$Union1FormBuilder( // It should be public
    model: _$Union1(text: 'foo'), // It should be Union1
    builder: (_, __, ___) {
      return Container();
    },
  );
}

  reactive_forms_generator: ^1.0.1

[vasilich6107]

Hi @MiniSuperDev
Could you clarify the usecase for unions in describing form models?

[MiniSuperDev]

Hi @vasilich6107
At the moment I have a notion type app, in which blocks of different types can be created.
In this case each type of block is a union class.

[MiniSuperDev]

@vasilich6107 In freezed for example to make json_serializable works with union, each union class should have its own annotations

[vasilich6107]

Hey @MiniSuperDev I probably realized the source of issue
Will try to fix some day

[smithemely]

Hi @vasilich6107,

We're also hoping for better support for Freezed unions. We use them a lot for dynamic forms, and improved handling in reactive_forms_generator would be very helpful for us.

Our specific use case involves Freezed unions where the structure and field types change based on a discriminator field. We define this using the unionKey parameter in the @Freezed annotation (e.g., unionKey: 'kind') and then use @FreezedUnionValue on each factory constructor to map to specific values of that discriminator.

For example, a simplified model might look like this:

// In our model file
enum AnswerKind {
  @JsonValue('text_response') textResponse,
  @JsonValue('date_response') dateResponse,
}

@Freezed(unionKey: 'kind') // 'kind' is our discriminator field
@RfGroup()
sealed class FormFieldResponse with _$FormFieldResponse {
  @FreezedUnionValue('text_response') // Maps to AnswerKind.textResponse
  const factory FormFieldResponse.asText({
    required String id,
    required AnswerKind kind, // The discriminator
    @RfControl() required String? actualAnswer,
    // ... other common fields
  }) = _FormFieldResponseAsText;

  @FreezedUnionValue('date_response') // Maps to AnswerKind.dateResponse
  const factory FormFieldResponse.asDate({
    required String id,
    required AnswerKind kind, // The discriminator
    @RfControl() required DateTime? actualAnswer,
    // ... other common fields
  }) = _FormFieldResponseAsDate;

  factory FormFieldResponse.fromJson(Map<String, dynamic> json) =>
      _$FormFieldResponseFromJson(json);
}

When reactive_forms_generator processes FormFieldResponse, the challenge we face is that the generated FormFieldResponseForm doesn't provide a way to access a type-safe FormControl for the actualAnswer field that matches its type in the specific union case. Instead, it appears to generate the FormControl for actualAnswer based only on the type found in the first factory encountered (e.g., String? from .asText in our example). Consequently, if a subsequent factory like .asDate defines actualAnswer as DateTime?, this distinction is lost in the generated form model.

This effectively forces all instances of the actualAnswer control to be treated as if they were of that initial type (e.g., String?). This limitation prevents us from directly using specialized reactive_forms_widgets like ReactiveDateTimePicker (which expects a FormControl<DateTime>) or other widgets that require FormControls with non-string types, as the generated control doesn't match the expected type for those union cases.

Ideally, the generated form model would allow us to interact with the actualAnswer control in a way that reflects its true type based on the active union case, determined by the kind field and the @FreezedUnionValue mapping.

We noticed your comment from September about looking into a fix. Could you share if there's any progress or an estimated timeline for when reactive_forms_generator might better support this unionKey / @FreezedUnionValue pattern for Freezed unions? It would be a significant improvement for building type-safe, dynamic forms.

Thanks for your work on this library.

[alejandrogiubel]

any update on this?