Idea: Extending dart_mappable Annotations for Enhanced Flexibility

[YousefAK009]

I would like to propose extending the @MappableClass and @MappableField annotations in dart_mappable to include some of the missing features available in freezed and introduce new capabilities that are not currently supported.

The core idea is to add the ability to incorporate custom and predefined hooks directly within these annotations. Additionally, enabling the annotations to read and interact with predefined fields would greatly enhance flexibility.

These enhancements would bridge existing gaps and empower developers to handle more complex scenarios seamlessly within the dart_mappable library.

class ExtendedMappableField extends MappableField {
  ExtendedMappableField({
    super.key,
    MappingHook? hook,
    bool ignoreFiled = false,
  }) : super(
          hook: ChainedHook([
            _ExtendedMappableFieldHook(key, ignoreFiled),
            if (hook != null) hook,
          ]),
        );
}

class _ExtendedMappableFieldHook extends MappingHook {
  final String? key;
  final bool ignoreFiled;

  const _ExtendedMappableFieldHook(this.key, this.ignoreFiled);

  @override
  Object? beforeDecode(Object? value) {
    // some logic
  }
}

[YousefAK009]

Hi @Schultek, I'd love to hear your thoughts on this. What do you think?

[schultek]

Is a subclassed hook like this being picked up by the generator? If not I can try to fix this.

I wouldn't want to add them itself to the package though, but its a nice option to have for users.

[YousefAK009]

Unfortunately, my current implementation won't work as intended because annotations need to be const to be effective, and there must be a mechanism to register these annotations so that the generator can recognize them.

I have two ideas to address this:

1. Extend Annotations with Hooks: If it's possible, we could extend the existing annotations to directly implement hooks within them. This would streamline the process and make it more intuitive.

2. Separate Annotation and Hook Classes: Alternatively, we could keep the annotation and hook classes separate. In this approach, a registry function would associate each annotation with its corresponding hook, allowing the generator to process them together.

I would appreciate any feedback or suggestions you might have on these approaches.