Suggest to use `json_serializable` instead of handwritten configuration deserialize code

[fzyzcjy]

json_serializable automatically generates a fromJson which inputs Map<String, dynamic> and outputs your struct. Seems that it supports yaml as well (though the name) - since this lib has already parse yaml into a Map.

[incendial]

@fzyzcjy could you add more details about the rule you want to add? Or it's not a rule? I'm a little bit confused.

[fzyzcjy]

Not a rule, just code refactor. Use https://pub.dev/packages/json_serializable instead of manually writing deserialize code.

[incendial]

What do you mean by "code refactor" in DCM terms?

[fzyzcjy]

https://en.wikipedia.org/wiki/Code_refactoring

[incendial]

Yeah, I got the idea of the suggestion, I'm trying to map it to current DCM entities like commands, rules, metrics, anti-patterns. So, you suggest a new entity, right?

[fzyzcjy]

I mean:

https://github.com/dart-code-checker/dart-code-metrics/blob/master/lib/src/analyzers/lint_analyzer/rules/rules_list/ban_name/utils/config_parser.dart

old code like

const _entriesLabel = 'entries';
const _identLabel = 'ident';
const _descriptionLabel = 'description';

/// Parser for rule configuration.
class _ConfigParser {
  static List<_BanNameConfigEntry> _parseEntryConfig(
    Map<String, Object> config,
  ) =>
      (config[_entriesLabel] as Iterable<Object?>? ?? []).map((entry) {
        final entryMap = entry as Map<Object?, Object?>;

        return _BanNameConfigEntry(
          ident: entryMap[_identLabel] as String,
          description: entryMap[_descriptionLabel] as String,
        );
      }).toList();
}

class _BanNameConfigEntry {
  final String ident;
  final String description;

  _BanNameConfigEntry({required this.ident, required this.description});
}

new code like

@JsonSerializable
class _BanNameConfigEntry {
  final String ident;
  final String description;

  _BanNameConfigEntry({required this.ident, required this.description});

  _BanNameConfigEntry.fromJson(Map<String, dynamic> json) => _$_BanNameConfigEntryFromJson(json); // <-- that _$ function is auto generated
}

[fzyzcjy]

then no need for manually writing the config parser

[incendial]

Ah, finally! Thank you for clarification. I though you're talking about suggesting json_serializable for the users of the package in their code 😅

[incendial]

As for your suggestion - I'm personally not a big fan of codegen, since it becomes a bit messy and slow from certain point. @dkrutskikh @roman-petrov what do you think?

[fzyzcjy]

since it becomes a bit messy and slow from certain point

If you mean slow when running codegen - I guess only seconds for this small codebase. And you can check in generated code into git, then users do not need to run again and again.

Codegen simplifies code and make codes less error-prone compared with manually writing

[incendial]

If you mean slow when running codegen - I guess only seconds for this small codebase

Build runner had this problem when you need to throw all genereated code and regenerate it all again. Is it fixed?

Codegen simplifies code and make codes less error-prone compared with manually writing

Agree 100%, for me it more about build runner developer experience

[fzyzcjy]

Build runner had this problem when you need to throw all genereated code and regenerate it all again. Is it fixed?

Still only seconds IMHO. Only do that when conflicts happen.

Agree 100%, for me it more about build runner developer experience

Well that is a tradeoff

[incendial]

Considering that the 'part' / 'part of' also negatively affects the analyzer performance and that the focus is now on the Teams version, I'm closing this one as won't fix.