feat: Added Form widget with form-validation support in Mirai

[i-asimkhan]

Description

Added Form widget with form-validation support in Mirai

Related Issues

Closes #107

Type of Change

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to change)
• Code refactor
• Build configuration change
• Documentation
• Chore

[RodolfoSilva]

I've also create a issue about a way to disable buttons and text fields when the form is in submiting mode.
#119

[i-asimkhan]

I've also create a issue about a way to disable buttons and text fields when the form is in submiting mode. #119

@RodolfoSilva Thanks for reviewing this. Your comment regarding key #110 (comment) makes a lot of sense and further, I can discuss this with @divyanshub024 but I am more interested in your bullet regarding button-disabling. It would be great if you elaborate more on this. 👍 👍

[RodolfoSilva]

Sure, I think we can add support for signals, and add the ability to widgets or actions react for signals. Imagine you have a widget thats emit a signal like, submitting and you have a widgets that subscribes when a signal occurs and apply some changes.

For example:

This widget emits a signal when the button is pressed:

{
  "type": "elevatedButton",
  "child": {
    "type": "text",
    "data": "Submit"
  }, 
  "onPressed": {
    "actionType": "signal",
    "name": "Mirai/submitting",
    "data": {},
    "then": {
      // run another action after the signal is emitted
    }
  },
  // ... other properties
}

Then you have a widget that subscribes to this signal and apply some changes to the widget:

{
  "type": "textFormField",
  "maxLines": 1,
  "obscureText": false,
  "onSignals": [
    {
      "name": "Mirai/submitting",
      "patch": {
        "readOnly": true,
        "enabled": false
      }
    }
  ],
  "readOnly": false,
  "enabled": true,
  // ... other properties
},

This will patch the properties to the widget when the signal is emitted, allowing you to create dynamic widgets that reacts to signals. Making the UI more dynamic and reactive.

The signal name, could be anithing defined by the user.

Sorry for the delay @i-asimkhan , I was on vacation.

[i-asimkhan]

Sure, I think we can add support for signals, and add the ability to widgets or actions react for signals. Imagine you have a widget thats emit a signal like, submitting and you have a widgets that subscribes when a signal occurs and apply some changes.

For example:

This widget emits a signal when the button is pressed:

{
  "type": "elevatedButton",
  "child": {
    "type": "text",
    "data": "Submit"
  }, 
  "onPressed": {
    "actionType": "signal",
    "name": "Mirai/submitting",
    "data": {},
    "then": {
      // run another action after the signal is emitted
    }
  },
  // ... other properties
}

Then you have a widget that subscribes to this signal and apply some changes to the widget:

{
  "type": "textFormField",
  "maxLines": 1,
  "obscureText": false,
  "onSignals": [
    {
      "name": "Mirai/submitting",
      "patch": {
        "readOnly": true,
        "enabled": false
      }
    }
  ],
  "readOnly": false,
  "enabled": true,
  // ... other properties
},

This will patch the properties to the widget when the signal is emitted, allowing you to create dynamic widgets that reacts to signals. Making the UI more dynamic and reactive.

The signal name, could be anithing defined by the user.

Sorry for the delay @i-asimkhan , I was on vacation.

That's a great illustration. Thank you 👍

[i-asimkhan]

Hey @RodolfoSilva
What are your suggestions about the MiraiFrom @freezed model class, would it better to follow flutter widget convention, like this

@freezed
class MiraiForm with _$MiraiForm {
  const factory MiraiForm({
    MiraiAction? onChanged,
    AutovalidateMode? autovalidateMode,
    required Map<String, dynamic> child,
    
  }) = _MiraiForm;

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

or we should make strict rules here by defining a list of child widgets (mainly form-inputs),

@freezed
class MiraiForm with _$MiraiForm {
  const factory MiraiForm({
    required List<Map<String, dynamic>> children,
    required MiraiSubmitAction action,
    
  }) = _MiraiForm;

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

[i-asimkhan]

Hey @RodolfoSilva What are your suggestions about the MiraiFrom @freezed model class, would it better to follow flutter widget convention, like this

@freezed
class MiraiForm with _$MiraiForm {
  const factory MiraiForm({
    MiraiAction? onChanged,
    AutovalidateMode? autovalidateMode,
    required Map<String, dynamic> child,
    
  }) = _MiraiForm;

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

or we should make strict rules here by defining a list of child widgets (mainly form-inputs),

@freezed
class MiraiForm with _$MiraiForm {
  const factory MiraiForm({
    required List<Map<String, dynamic>> children,
    required MiraiSubmitAction action,
    
  }) = _MiraiForm;

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

Secondly, we need to partition the business logic from the MiraiAction as it is becoming more and more detailed.
One of the thoughts I have is to make a generic type of Action and then extend many other types of actions, just like you did in LsdAction here

The problem with @freezed models is that we can use the language feature , so there is another possibility that we make whole new action for submit as you have in LSD called MiraiFormSubmitAction and use its own implementation to handle the form submission.

[RodolfoSilva]

Hey @RodolfoSilva What are your suggestions about the MiraiFrom @freezed model class, would it better to follow flutter widget convention, like this

@freezed
class MiraiForm with _$MiraiForm {
  const factory MiraiForm({
    MiraiAction? onChanged,
    AutovalidateMode? autovalidateMode,
    required Map<String, dynamic> child,
    
  }) = _MiraiForm;

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

or we should make strict rules here by defining a list of child widgets (mainly form-inputs),

@freezed
class MiraiForm with _$MiraiForm {
  const factory MiraiForm({
    required List<Map<String, dynamic>> children,
    required MiraiSubmitAction action,
    
  }) = _MiraiForm;

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

@i-asimkhan I prefer the first approach. it's more composable than the second. It is closer to HTML form and Flutter Form. This allows the user to decide what kind of child to use. I understand that the second approach will by default have a column implementation.

[RodolfoSilva]

Hey @RodolfoSilva What are your suggestions about the MiraiFrom @freezed model class, would it better to follow flutter widget convention, like this

@freezed
class MiraiForm with _$MiraiForm {
  const factory MiraiForm({
    MiraiAction? onChanged,
    AutovalidateMode? autovalidateMode,
    required Map<String, dynamic> child,
    
  }) = _MiraiForm;

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

or we should make strict rules here by defining a list of child widgets (mainly form-inputs),

@freezed
class MiraiForm with _$MiraiForm {
  const factory MiraiForm({
    required List<Map<String, dynamic>> children,
    required MiraiSubmitAction action,
    
  }) = _MiraiForm;

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

Secondly, we need to partition the business logic from the MiraiAction as it is becoming more and more detailed. One of the thoughts I have is to make a generic type of Action and then extend many other types of actions, just like you did in LsdAction here

The problem with @freezed models is that we can use the language feature , so there is another possibility that we make whole new action for submit as you have in LSD called MiraiFormSubmitAction and use its own implementation to handle the form submission.

I totally agree. Such a move will unlock a wealth of possibilities and customization options. It will empower us to utilize any other navigation library, such as go_router, or to modify the existing implementation. Additionally, partitioning would enable us to relocate MiraiForm into a distinct package.

When I started building LSD, I was thinking about composability and customization being in the control of the user who is using the library.