Feature Request: Support Generation from Domain Models

[etegan]

Hello and first of: Thanks for these great packages!

Problem Statement

Currently, the generator requires models with nullable fields to represent form state, forcing developers to maintain two parallel models:

1. A domain model with proper nullability representing the business logic
2. A form state model with nullable fields for form handling

This leads to unnecessary duplication and makes it harder to maintain type safety between form submissions and domain objects.

Example of current approach:

// Domain Model
class User {
  final String name;      // Required in domain
  final String email;     // Required in domain
  final String? phoneNumber;
}

// Currently needs manual form model
class UserFormModel {
  final String? name;     // Must be nullable for form
  final String? email;    // Must be nullable for form
  final String? phoneNumber;
}

Proposed Enhancement

The generator should automatically generate both:

1. The form model class with appropriate nullable fields
2. An extension method on the domain model for conversion

The @Rf annotation should support configuring partial data injection through related models.

Example Usage

// Domain model with partial data configuration
@Rf(partialData: {
  'UserInvitation': {
    'email': 'email'  // maps invitation.email to userFormModel.email
  }
})
class User {
  final String name;
  final String email;
  final String? phoneNumber;
}

// Generated form model with inferred validators
class UserFormModel {
  final String? name;     // Generated with RequiredValidator() since non-nullable in User
  final String? email;    // Generated with RequiredValidator() since non-nullable in User
  final String? phoneNumber;  // No RequiredValidator() since nullable in User
}

// Generated extension
extension UserFormExtension on User {
  UserFormModel get formModel => UserFormModel(
    name: name,
    email: email,
    phoneNumber: phoneNumber,
  );
}

// Usage in UI
UserFormBuilder(
  // Optional initial data from domain model using generated extension
  model: existingUser?.formModel,  
  // Partial data injection configured by @Rf annotation
  userInvitation: UserInvitation(email: "example@email.com"),
  builder: (context, form, child) => ...
)

Benefits

• Reduces boilerplate and maintenance overhead
• Maintains single source of truth for model structure
• Preserves type safety throughout the form lifecycle
• Enables better IDE support and static analysis
• Allows seamless integration with domain-driven design practices
• Provides clean, intuitive API through generated extensions on domain model class
• Declarative configuration of partial data injection
• Automatic validation rules based on domain model nullability

Implementation Notes

The generator would need to:

1. Analyze domain model field nullability
2. Parse @Rf annotation for partial data configuration
3. Generate form state model with nullable fields
4. Generate validation rules based on domain model nullability
5. Generate extension methods for converting domain models to form models
6. Generate partial data injection logic based on annotation configuration

Would you consider this enhancement for a future release? It would significantly improve the developer experience when working with domain-driven architectures.

[vasilich6107]

Hey @etegan
check https://pub.dev/packages/reactive_forms_generator/versions/6.0.0-beta.16

[vasilich6107]

It generates output based on the RequiredValidator and generates ...Output form with proper nullability items

Here is an example
https://github.com/artflutter/reactive_forms_generator/blob/bets/packages/reactive_forms_generator/example/lib/docs/login/login_output.dart

For now not every aspect is working but you can try

[vasilich6107]

The solution with JSON

@Rf(partialData: {
  'UserInvitation': {
    'email': 'email'  // maps invitation.email to userFormModel.email
  }
})

is not scalable cause it falls apart in complex cases due to the lack of static analysys
The main idea of generator to get a statically reliable result as much as possible

[etegan]

Fantastic! Thanks for the quick reply. I realised that a lot of the functionality I was looking for was also available by writing named constructors on the model 😊

[github-actions]

Hi @etegan!
Your issue has been closed. If we were helpful don't forget to star the repo.

Please check our reactive_forms_widget package

We would appreciate sponsorship subscription or one time donation
https://github.com/sponsors/artflutter

[etegan]

Hello again. I noticed what I think might be a bug. The named constructor approach that I mentioned together with the @RfArray annotations results in a UserForm without the add* methods

class User {
  final String name;
  final List<String> roles;

  // Without this constructor the addRolesItem is generated
  const User.withDefaults({
    this.name = '',
    this.roles = const [], // Problem: @RfArray won't generate addRolesItem
  });

  const User({
    @RfControl(validators: [RequiredValidator()])
    required this.name,
    @RfArray(validators: [RequiredValidator()])
    required this.roles,
  });

}

[etegan]

Solved: the named constructor can not be the first constructor. This works:

class User {
  final String name;
  final List<String> roles;

  const User({
    @RfControl(validators: [RequiredValidator()])
    required this.name,
    @RfArray(validators: [RequiredValidator()])
    required this.roles,
  });
  
  // Named constructor comes after default constructor
  const User.withDefaults({
    this.name = '',
    this.roles = const [],
  });

}

[github-actions]

Hi @etegan!
Your issue has been closed. If we were helpful don't forget to star the repo.

Please check our reactive_forms_widget package

We would appreciate sponsorship subscription or one time donation
https://github.com/sponsors/artflutter

[etegan]

Leaving it open if you still want to classify it as a bug :)

[vasilich6107]

so technically it is a bug casue I'm just taking first constructor among available.
this becomes even trickier as far as generator supports annotatless behavior and treats the un-unnotated field as just a control
This was made to simplify working with values which does not have annotation and were processed separately to have an ability to pass through the values.

i refined more the v6 and currently we are going to start migrating our prod so it is more safe to use so you do not need any tricks with constructors.

[benji-farquhar]

So to get the required fields correct in the output model, we add a string version of its validator, to the requiredValidators, in order of field of the class?

So for this model:

@RfGroup(
  validators: [MustMatchValidator()],
)
class LoginO extends Equatable {
  final String? email;

  final String? password;

  const LoginO({
    @RfControl(
      validators: [RequiredValidator(), RequiredValidator()],
    )
    this.email,
    @RfControl(
      validators: [RequiredValidator2()],
    )
    this.password,
  });

  @override
  List<Object?> get props => [email, password];
}

to get only password required:

  requiredValidators: [
    'RequiredValidator2()',
  ],

to get only email required:

  requiredValidators: [
    'RequiredValidator()',
  ],

to get both required:

  requiredValidators: [
    'RequiredValidator()',
    'RequiredValidator2()',
  ],

Would this behaviour be the same if it uses validators other than required validators?

Can you add this behaviour to the readme? It doesn't seem obvious.