Flutter Freezed Plugin v4.0.0

[Parables]

I want to begin by expressing my profound gratitude to the team at the Guild especially @charlypoly

A tool is supposed to help you make the work simple, not let you do the work. I created this plugin because I dread writing Freezed models for a very big GraphQL Schema. I decided to invest the time into building a tool that can take the schema and churn out Freezed models and regenerate them when my schema changes hence flutter-freezed was created

The last version of the flutter-freezed plugin had some issues identified by @endigo.
@auaicn submitted some PRs that fixed these issues
And then I realized something when I made this comment.

If you wanted to configure certain things like making certain fields final, deprecating some factories or passing in a custom-encoding for fromJson and toJson, and you had to apply these configurations to more than one Graphql Type, you would have to manually list each Type in the config and repeat the same configuration for each type. This could easily result in a very bloated config file.

Using @endigo GraphQL Schema for example, imagine how tedious it would be to specify the configuration for about 20 GraphQL Types

Over the weeks I have been working on a new version of the flutter freezer plugin in a sandbox repo.

What's New in v4.0.0

The new version v4.0.0 comes packed with the following changes

Major refactoring.

The previous version used a lot of side effects, mutating states of the properties of the various blocks to produce the expected output. This made it really hard to track and find why the plugin produced a certain output.

In this issue, I requested @auaicn to help me out with a bug that caused the plugin to generate the wrong output. It took me weeks but to no avail in my effort to debug and fix the issue until I eventually gave up and realized I was doing this whole thing the wrong way and so there was a big rewrite

This time around, I went with the functional approach and used functions everywhere for everything. This really made it easy to test each function and find bugs easily.

A more compact config

Using Typescript's Record<K, V> was great for auto-completion support. While this wasn't entirely bad, I found it really tedious specifying the keys and value pairs for each option.

Then it struck me, we write CSS and use shorthands like margin: 10px 20px and that produces a 10px vertical margin and a 20px horizontal margin. Could this plugin benefit from using these shorthands?

Before

escapeDartKeywords?:
        | boolean
        | Record<string,  {
              dartKeywordEscapeCasing?: DartIdentifierCasing;
              dartKeywordEscapePrefix?: string;
              dartKeywordEscapeSuffix?: string;
            }>;

After

  escapeDartKeywords?:
    | boolean
    | [
        typeFieldName: TypeFieldName,
        prefix?: string,
        suffix?: string,
        casing?: DartIdentifierCasing,
        appliesOn?: AppliesOnParameters[]
      ][];

Over here, we are trading auto-complete and a bloated but readable config for a compact, less readable but clean syntax.
It may be confusing at first glance, but once you get a hang of it, you will appreciate the simplicity it offers.

The most specific change in this version is the introduction of the TypeFieldName which allows you to specify the same configuration to multiple fields of multiple types in a single declaration. Here is a gist of what it can do.

Using some verbose RegExp, it scans the config for TypeFieldName patterns and recursively applies the configuration until the end of the config for that option.

This replaces using typeSpecificFreezedConfig and globalFreezedConfig as you can specify both of them in one or more declarations of a TypeFieldName

There is definitely a trade-off going on here: You are still sacrificing time here, but it is at the expense of computational power, not human effort.

This new addition has got me thinking if this is the right way forward. Instead of explicitly manually listing each Type and field just to apply some configuration option, you use some patterns and let the plugin go figure that out.

This is where I would like your feedback on the following

1. Do you configure the flutter-freezed plugin in your project
2. What configuration options do you heavily rely on?
3. How is the experience when configuring the plugin?
4. Do you think it a good idea to specify config using well-defined patterns and let the plugin figure that out
5. What do you think of the RegExp used in the pattern matching
6. What are your pain points using this plugin
7. Relating to Flutter and GraphQL, how can we improve the DevX by taking inspiration from KitQL
8. Anything else I am missing?