FlutterJsonBeanFactory generates Dart bean classes from a JSON payload inside the IDE

The boilerplate this plugin removes

Flutter applications that talk to a REST API end up with the same layer of code in every project. A Dart class with a handful of fields, a factory constructor that reads a JSON map, a toJson method that writes it back, and a helper that turns a dynamic value into the right type with a null check on each line. None of it is interesting, and all of it has to be kept in step with the API shape. The plugin's stated job is to generate Dart bean classes based on JSON, along with generic parameters and JSON built instances, and the feature list is specific about what that covers: support for instantiation through generics, support for customised JSON parsing, support for int, double, String, datetime, dynamic and var types plus lists of those, two dimensional and higher arrays from version 4.5.6, and a custom generated path. The intended user is a Flutter developer inside an IDE, since the whole thing is delivered as an IntelliJ platform plugin rather than a command line tool. That delivery choice is the project, in both senses.

How the generation actually happens

The mechanism is IDE side and file based. The plugin installs into the IDE, you paste or point it at a JSON payload, and it writes a Dart class plus supporting files into a generated directory in your project. The project description states that the generated method regenerates all helper classes and JsonConvert classes each time an entity file is created in the generated/json directory, which is the important operational detail: the generated tree is owned by the plugin, and the helper base class is regenerated rather than left alone for you to edit. That is also why customisation happens through a different route than editing the generated file, which is what the custom parsing snippet demonstrates.

The generated classes are organised in two layers. The per-entity class holds your fields and the two conversion methods, and the shared JsonConvert class holds the generic conversion helper that all entities use. The typed conversion entry point is JsonConvert.fromJsonAsT<T>, and the project description notes that you can call it directly when you need generic conversions in your network requests, which is what lets a response be decoded into a typed object without naming the entity class at the call site. The file layout follows from that: an entity file in generated/json, and the shared helper under generated/json/base, with a content file naming it in the custom parsing example.

Custom parsing, which is where you will actually need it

A generated parser that only handles strings, numbers and booleans is fine on day one and wrong by the first real API, because dates arrive as strings in some format rather than as numbers. The plugin provides the escape hatch for this: you write your own class extending JsonConvert, override the generic asT method, and assign it to the global jsonConvert variable before your app starts. The example does exactly that for a DateTime, parsing with a day, month and year pattern instead of the default, and falls back to the base implementation for everything else, with a try and catch that prints the error and returns null. The class is then installed with a single assignment in main before runApp.

import 'generated/json/base/json_convert_content.dart';

class MyJsonConvert extends JsonConvert {
  T? asT<T extends Object?>(dynamic value) {
    try {
      String type = T.toString();
      if (type == "DateTime") {
        return DateFormat("dd.MM.yyyy").parse(value) as T;
      } else {
        return super.asT<T>(value);
      }
    } catch (e, stackTrace) {
      print('asT<$T> $e $stackTrace');
      return null;
    }
  }
}

One thing is worth flagging because it is easy to get wrong. The catch block returns null, so a malformed date silently produces a null field rather than an exception. For a date of birth or an expiry timestamp that is a real hazard, and the fix is to tighten the override rather than to accept the generated behaviour. The base class path also shows that the generated code is not the only source of the conversion logic, since your subclass sits in front of it and decides what happens for the types you care about.

Installing the plugin and generating your first bean

Installation follows the standard IntelliJ marketplace route. Open Settings or Preferences, go to Plugins, then Marketplace, search for FlutterJsonBeanFactory and install it, then restart the development tool. The project description also notes that the plugin was built with free open source IDE licences granted by JetBrains, which is why it is free and why the project acknowledges them at the end of its description.

After the restart, you configure the plugin in the YAML file of the Flutter project. The only documented key is the generated path:

flutter_json:
  generated_path: src/json/**

That block redirects the output away from the default location, which matters if your project keeps generated code out of the source root or in a folder that your lint rules treat differently. Then you invoke the plugin, with the shortcut alt plus j on mac, or by right clicking on the package and choosing New and then Dart bean class from JSON, and the project description says you will know how to use it from there. Once a class exists, you can change its fields and press alt plus j again to regenerate the toJson and fromJson methods, which is the workflow that makes the tool worth installing: the model is edited in Dart, and the parsing code follows.

There is a known issue worth reading before you file a bug. If the plugin reports that no classes that inherit JsonConvert were found, the fix given is to delete the .idea directory under the project and invalidate caches and restart the IDE, in Android Studio or IDEA. The same remedy is given for the case where no helper files are generated at all.

The release history gap, and what it means for a Flutter project

Here is the awkward part of the facts. The repository records a last push on 2026-07-28, so the code is being touched, and it is not archived. But the published release list stops at version 3.3.1, with builds 191, 192 and 193 all dated 2020-01-13. The repository also carries a CHANGELOG.md, a CODEOWNERS file, a qodana.yml configuration and a Gradle build with build.gradle.kts, settings.gradle.kts and gradle.properties, which is the shape of a project that keeps its own build rather than depending on an external generator tool. The build files and the recent push suggest the work on the plugin continues even though the marketplace version tags are old, and the array support note in the README is marked as arriving in version 4.5.6, which is well past 3.3.1, so the repository's own documentation and the GitHub release list are describing different things.

The practical consequence for an adopter is that you cannot rely on the tag list to tell you what version the marketplace is serving. The array support note points at 4.5.6 as the version where two dimensional arrays arrived, so the installed plugin is at least that, and the changelog is the place to check for behaviour changes between your version and the one you upgrade to. The repository is Apache-2.0 licensed, so there is no copyleft obligation on the code you generate or on an application that uses the plugin, which is a favourable position for commercial work.

Where a JSON to Dart generator is the wrong choice

Two boundaries stand out. The first is that the plugin only helps with JSON. If your Flutter app receives protobuf, Freezed unions or a typed GraphQL schema, the boilerplate you want to remove is generated by a different set of tools, and this plugin will not help. The second and sharper one is the crowded ecosystem. The mainstream Flutter approach for this problem is build_runner with json_serializable, where you annotate a Dart class with a part directive and a generated mixin is produced by a running build step rather than by a keystroke in the IDE. The difference in approach is where the generation happens. The plugin generates on demand, from a JSON payload pasted into a dialog, so the model class and the JSON are the source of truth and the two can drift apart, since a field added by hand to the class is not reflected in the JSON. The build_runner approach inverts that, making the annotated Dart class the source and generating the parsing code from it, so the JSON shape is described by the class and the code is always consistent with it.

That inversion is the argument for build_runner and against this plugin for a new project, and it also explains what this plugin is genuinely good at. It is fast when you are bringing up a new endpoint and want a typed model in thirty seconds, it works without touching your build configuration, and it needs no annotations on your classes. It is worse as a long-term convention for a codebase with many models, where a single generation tool owning both the entities and the shared helper class is a fine thing to have but is one more thing to configure, and where a stale IDE cache can stop the plugin from finding your own classes at all.

Editorial conclusion

Adopt FlutterJsonBeanFactory if you work in Flutter with IntelliJ IDEA or Android Studio and you want typed Dart models from JSON without writing the parsing methods by hand. Do not adopt it if your project has already settled on a different generation approach, such as build_runner with json_serializable, since running two generators over the same models is a conflict waiting to happen. Before you install it, note that the published releases stop at version 3.3.1 from January 2020 while the last push to the repository was on 2026-07-28, so check that it still works with your Flutter and Dart versions, and read the custom parsing snippet in the project description, because your date formats usually need it.

Frequently asked questions

Official sources

1. fluttercandies/FlutterJsonBeanFactory on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases