DEV Community: Nikita Sin

DuitDataSource: The Data Layer That Quietly Changed Everything in Duit

Nikita Sin — Fri, 27 Mar 2026 07:36:13 +0000

1000 widget update iterations: about 1.9 seconds with the old attribute-based approach, 114 ms with the newer one.

That gap is the reason this article exists.

In Duit, widget updates used to revolve around attribute classes: parse JSON into Dart objects, create new attribute instances for every update, then merge old and new state to produce the final result. It was structured. It was explicit. In a hot path, especially during animations, it was also too expensive.

Each update meant more parsing, more copying, more object allocation, and more boilerplate than the framework was getting back in value. In the most expensive scenarios, that translated into more GC pressure and slower frame preparation.

The improvement did not come from one clever micro-optimization. It came from changing the role of data in the framework.

This article explains why DuitDataSource is not just a typed wrapper around Map<String, dynamic>, but the runtime layer that now handles parsing, partial updates, memoization, and a large share of the framework's hot-path optimization work.

For a bit of context: Duit is a BDUI framework for Flutter. It lets teams describe UI remotely and turn structured payloads into native Flutter widgets, actions, commands, and runtime behavior on the client.

That solves a very practical set of problems. It helps ship UI changes faster, reduces the amount of client-side release work for presentation-level updates, and gives smaller teams access to a BDUI-style architecture without having to build an entire internal platform from scratch.

The old problem was not "JSON"

The obvious explanation would be: "JSON is dynamic, typed attribute classes are safer, therefore classes are the right abstraction."

That sounds good until you have to live with the consequences:

every widget needs a dedicated attribute model
every update creates intermediate objects
merge logic becomes both repetitive and fragile
animations magnify the cost because the same properties are touched again and again

The problem was not that the framework started from Map<String, dynamic>.

The problem was converting that map into too many short-lived objects too early, then paying the price for that decision on every update.

So I went back to the thing I originally tried to avoid: a plain Map<String, dynamic>.

Not raw. Not unstructured. Not "just trust the payload".

Wrapped.

Why `DuitDataSource` exists

DuitDataSource is an extension type over Map<String, dynamic>:

extension type DuitDataSource(Map<String, dynamic> _json)
    implements Map<String, dynamic> {
  // typed accessors and converters
}

It keeps the cheap and flexible storage model of a map, but exposes strongly typed getters and conversion methods for Flutter and Dart values: colors, durations, alignments, curves, borders, actions, animation settings, command payloads, and many other property types.

So the framework no longer needs a dedicated "attributes class" per widget just to say "this JSON field is a Color, this one is an EdgeInsets, this one is a Duration."

Instead, DuitDataSource becomes a typed access layer over the payload that already exists.

What role it plays in the current project

Today DuitDataSource is not a small helper. It is one of the core runtime abstractions in Duit.

It plays at least four different roles.

1. Boundary between remote JSON and native Flutter types

This is the most visible role.

Transport code receives JSON. Widgets, commands, and actions need Flutter-native values. DuitDataSource is the boundary where that transformation happens.

For example, transport decoding can optionally use DuitDataSource.jsonReviver during jsonDecode:

return jsonDecode(
  utf8.decode(data),
  reviver: DuitDataSource.jsonReviver,
) as Map<String, dynamic>;

Then higher layers wrap the payload with DuitDataSource and read typed values instead of manually parsing maps all over the codebase:

final source = DuitDataSource(command.commandData);

return BottomSheetCommand(
  content: source["content"] ?? const {},
  backgroundColor: source.tryParseColor(key: "backgroundColor"),
  shape: source.shapeBorder(key: "shape"),
  clipBehavior: source.clipBehavior(key: "clipBehavior"),
  onClose: source.getAction("onClose"),
  action: OverlayAction.parse(source.getString(key: "action")),
  // ...
);

The effect is simple and important: parsing logic stops leaking into every command, widget, and adapter.

The framework gets one place where data is interpreted, and the rest of the runtime gets to consume typed values.

2. Update substrate for widget changes and animations

This is where the "it is just a typed map wrapper" explanation stops being enough.

In the current project, DuitDataSource is also the object that updates flow through.

Animated properties are merged directly into the same data source:

mixin AnimatedAttributes on Widget {
  DuitDataSource mergeWithDataSource(
    BuildContext context,
    DuitDataSource dataSource,
  ) {
    final parentId = dataSource.parentBuilderId;
    if (parentId == null) return dataSource;

    final animationContext = DuitAnimationContext.maybeOf(context);
    if (animationContext == null) return dataSource;
    if (animationContext.parentId != parentId) return dataSource;

    final affectedProps = dataSource.affectedProperties;
    if (affectedProps == null || affectedProps.isEmpty) {
      return dataSource;
    }

    final animatedProperties = <String, dynamic>{};

    for (final prop in affectedProps) {
      final value = animationContext.streams[prop]?.value;
      if (value != null) {
        animatedProperties[prop] = value;
      }
    }

    return dataSource..addAll(animatedProperties);
  }
}

DuitDataSource is no longer only the thing that reads properties. It is also the thing that receives partial updates, applies merges, and becomes the mutable substrate for the final widget state.

This is why it matters so much in animation-heavy scenarios. The framework does not need to keep manufacturing replacement attribute objects just to override one or two fields for the next frame.

It can merge the changed values into the current data structure and move on.

3. Memoization layer, not just a parser

This is the role that ended up being the most important.

At first glance, a method like tryParseColor() looks like a parser helper. In reality, it is doing something more valuable: it memoizes the parsed result.

After the first successful conversion, the native object is written back into the underlying map:

Color? tryParseColor({
  String key = FlutterPropertyKeys.color,
  Color? defaultValue,
  Object? target,
  bool warmUp = false,
}) {
  final value = _readProp(key, target, warmUp);

  if (value is Color) return value;
  if (value == null) return defaultValue;

  switch (value) {
    case String():
      return _json[key] = _colorFromHexString(value);
    case List():
      return _json[key] = _colorFromList(value);
    default:
      return defaultValue;
  }
}

The same pattern appears across many accessors: colors, durations, enums, alignments, sizes, actions, and more.

That changes the economics of repeated reads.

The first access pays the parsing cost. The next access often becomes a cheap "already typed, return as is" path. In a static payload, that is nice. In repeated rebuilds and animations, that is a major win.

That is why I would describe the current role of DuitDataSource like this:

It is not primarily a JSON parser. It is a memoizing typed data layer for a remote UI runtime.

That distinction matters because it explains both the API and the performance profile.

4. A deliberate performance lever

Once DuitDataSource became the center of property access, it also became the right place for low-level optimization.

That is where optimizations like these start to pay off:

replacing attribute object copying with map merge semantics
reusing already parsed native values
using lookup tables for enum-like conversions
keeping hot functions small enough to be good candidates for @pragma('vm:prefer-inline')
using jsonReviver and warm-up dispatch to front-load selected conversions

This matters because DuitDataSource methods are not called once in a while. They are called everywhere:

while decoding transport responses
while creating commands
while building widgets
while resolving styles
while applying animated updates

If a function in that path becomes 15% faster, it is not an academic improvement. It compounds.

And if a function in that path avoids allocations entirely, the gain is not just raw CPU time. It is also lower GC activity and more predictable runtime behavior.

Why extension types were the right tool

Without extension types, this design would be much less attractive.

Using a wrapper class would introduce more ceremony and potentially more overhead. Using a raw map directly would destroy the ergonomics and safety of the API.

Extension types make it possible to keep the data representation simple while still exposing a rich, typed interface.

That is the real trick behind DuitDataSource.

The representation stays simple, while the API remains typed and the hot path stays cheap.

What this changed for the framework

The benefits go beyond benchmark charts.

Moving the framework around DuitDataSource changed several things at once:

less widget-specific boilerplate
fewer fragile merge/copy implementations
fewer intermediate objects in the update pipeline
simpler APIs for commands, custom widgets, and model construction
a better foundation for tooling built around Duit

This is also why DuitDataSource matters to the future of the project, not just to one optimization pass.

When the core runtime speaks a consistent typed-map language, other parts of the ecosystem get easier to build. Tooling, editor integrations, debugging helpers, visual builders, and migration utilities all benefit from that simplification.

From that perspective, DuitDataSource is not a utility type.

It is the data contract the runtime now organizes itself around.

The bigger lesson

The interesting part of this story is not "maps are faster than classes."

That would be too shallow, and often false outside the specific workload.

The real lesson is that the best abstraction is the one that matches the runtime behavior you actually need.

In Duit, the hot path was not "create beautiful immutable attribute models." The hot path was:

receive remote payload
read a lot of properties repeatedly
update only a small subset of them frequently
avoid extra allocations while doing it

Once I looked at the problem through that lens, DuitDataSource stopped being an implementation detail and became the right architectural center.

That is its role in the project today.

It is the layer that turns dynamic payloads into typed Flutter data, the object that absorbs partial updates, the cache that avoids reparsing work, and the lever that lets performance work scale across the entire runtime.

Not bad for something that started as "maybe I should just use a map."

Practical takeaway

If you are building a remote UI system, a config-driven runtime, or any framework that repeatedly interprets structured data, do not ask only:

"How do I make this typed?"

Also ask:

"Where will this data live after the first parse?"
"How many times will I read it again?"
"Can the same structure be both the source of truth and the cache?"

In Duit, that set of questions led to DuitDataSource. Once it did, a lot of other pieces started to fall into place.

If you want to dig into the implementation, start here:

You didn’t understand Extension Types in Dart

Nikita Sin — Thu, 03 Jul 2025 07:10:00 +0000

Dart continues to evolve, gaining new language features. While extension methods have become an everyday tool, extension types remain in the shadows — completely undeservedly. Why has such a powerful mechanism been underappreciated? In what cases is it truly indispensable?

In this article, we’ll reflect on Dart’s evolution in the context of static type extensions and explore practical use cases for extension types.

Hi! My name is Nikita Sin. I’m a lead Flutter developer at betting company BetBoom, the author of the BDUI framework for Flutter — Duit. I’m also the leader of the mobile developers’ community Mobile Assembly | Kaliningrad.

I’d bet that you use static type extensions every day! But, as my experience studying open-source library code and interacting with other developers shows, many Dart users still haven’t fully appreciated the power of extension types. This isn’t just "another way to add a method" — it’s a fundamentally different approach to working with types in Dart!

This situation doesn’t sit well with me. I’m here to show you the full potential of this awesome feature by digging deeper than superficial overviews. Let’s start from the very beginning — with the introduction of extension methods — so we can trace how Dart evolved toward extension types.

The history of static type extensions: Extension Methods

The release of Dart 2.7 on December 11, 2019, brought several changes, including a new feature — extension methods (hereafter, EM).

In a way, this was a revolution, providing developers with a solution to one of the language’s fundamental problems: extending the functionality of closed or third-party types.

Today, it’s simply impossible to imagine code without extensions. Many libraries (like go_router, bloc, etc.) rely on them, with a common use case being extending BuildContext. And all this without modifying source code, creating wrappers, or using inheritance!

But time doesn’t stand still, and the Dart team has introduced entirely new concepts to the language.

Extension Types

While EM allowed adding new methods to existing types, the introduction of extension types (hereafter, ET) in Dart 3.3 took things further — enabling the creation of new static types on top of existing implementations.

This is a fundamentally different level of abstraction. But as I began studying this feature more closely, I encountered an interesting paradox: despite its depth and capabilities, ET "remain in the shadows," underutilized by most developers.

The situation becomes even more intriguing when you realize that the only widespread example of ET usage is package:web, one of the key packages for the Dart/Flutter ecosystem. Outside of web development, they’re almost absent in popular packages.

Does this mean the feature is weak, or have we simply not yet realized its potential? Let’s figure it out!

Key similarities and fundamental differences

I remember my first encounter with ET. At first, it was completely unclear why we needed an "analog" of the already existing EM, since at a glance, they seemed very similar:

Both EM and ET work with existing types, adding functionality to types you can’t or don’t want to modify directly (e.g., types from dart:core, classes from third-party libraries).
Neither EM nor ET create additional objects in memory when called — the compiler "unwraps" them during compilation.
At runtime, the value remains an instance of the original type (int, String, etc.). No surprises with sudden type changes.
Both mechanisms allow adding methods, getters, setters, and overriding operators that work with instances of the type.

But all of the above is just the tip of the iceberg. Despite their apparent similarity, the differences between the two mechanisms are significant, both in terms of capabilities and conceptually. Let’s examine them in more detail.

While EM "simply" adds new methods to an instance of an existing type, ET creates a new type based on the underlying one, effectively introducing an abstraction that the compiler treats as an independent type.
EM is automatically compatible with all instances of the extended class (e.g., every int has methods from extension on int). ET, however, requires explicit "wrapping" of the base type instance and explicit type casting.
ET supports static members — you can declare static methods, fields, named constructors, and factory constructors.
One of ET’s key features is member hiding, allowing control over the API of any type in Dart.
ET carries not only new or overridden functionality for the base type but also semantic meaning. EM, on the other hand, is perceived more as a set of utility methods.

Extension types in action: `package:web`

With theory out of the way, let’s look at a real-world example of ET usage. I wondered: "Why were ET used in package:web instead of regular extensions?" and found several key reasons:

Ensuring type safety. Even with extension on JSObject, all JS objects remain the same type—the compiler doesn’t distinguish between Window, HTMLElement, etc. ET creates objects of unique types, even though at runtime they’re still JSObject. The Dart compiler prevents confusion between objects.

// Without ET: Runtime error only  
Window window = getWindow();  
window.querySelector('div'); // Window doesn’t have this method!

Abstraction without overhead. The eternal problem with any wrapper classes is extra memory allocations. For performance-critical systems, this is a crucial factor to avoid. ET doesn’t create additional objects at runtime while adding compile-time type safety guarantees. In package:web, frequent JS-API calls (e.g., in animations or event handling) would cause GC pressure and FPS drops if full wrapper objects were created. ET enables both maximum performance and resource efficiency—the wrapper exists only at the type level, with direct JS-object access at runtime.

JS interaction semantics. The package:js library worked with the dynamic type, which was far from ideal. This made the code unsafe, as errors could only be caught at runtime. ET changes the game: all JS objects remain statically typed, and development becomes more convenient thanks to autocompletion.

// Highly simplified ET declaration for JS objects:  
extension type Window(JSObject _) implements JSObject {  
  external Document get document;  
  external void alert(String message);  
}  

extension type Document(JSObject _) implements JSObject {  
  external HTMLElement? querySelector(String selector);  
}  

extension type HTMLElement(JSObject _) implements JSObject {  
  external DOMTokenList get classList;  
}

Why haven’t Extension Types "taken off"?

The paradox of ET is that their success case has also become their curse. While demonstrating the power of the concept, package:web is a niche domain for most developers, making ET seem overly complex to learn.

So why don’t we see widespread ET adoption?

Cognitive load. The concept of a static wrapper that exists only at compile-time requires a paradigm shift. Developers are used to two typical models:

Creating wrapper classes with inherent overhead.
Using extension methods for utility functions.

ET, however, is a hybrid—you create a new type (e.g., UserId), but it disappears at runtime. This causes dissonance, forcing developers to constantly keep the difference between static and runtime semantics in mind.

Lack of design practices. ET solve a narrow set of problems: optimizing wrapper classes, typed and protected interfaces. But these scenarios rarely arise in everyday app development. When they do, developers don’t associate them with ET. There’s no established understanding of how to design ET or when to choose them over classes.

Synthetic examples. Dart’s documentation offers examples like wrapping an ID over int. While technically correct, this doesn’t showcase ET’s full potential—and frankly, it’s uninspiring. Why use ET when typedef works?

The lack of a "bridge" between UserID(int id) and package:web, combined with the need to consider new language features during design, has led to this genuinely cool Dart feature remaining underutilized.

Constructive criticism is good, but there’s a saying: "If you criticize, suggest." I invite you to consider a more "real-world" application of this powerful Dart feature.

Encapsulating internal logic and object-oriented interaction with procedures

Imagine this scenario: you’re working with low-level APIs or a set of procedures. A common challenge developers face is the lack of an expressive API, which can lead to hard-to-diagnose errors.

As an example, let’s take working with isolates, where procedural style dominates, requiring manual port management. This is a powerful but low-level mechanism where mistakes are easy to make. ET offers an alternative, allowing elegant object-oriented contracts on top of low-level mechanisms. Let’s see how Dart’s ET can adapt the base isolate worker implementation for specific tasks.

First, let’s implement a basic worker class:

// Base worker implementation
final class Worker {  
  final SendPort sP;  
  final ReceivePort rP;  
  final Isolate isolate;  

  Worker._(  
    this.isolate,  
    this.sP,  
    this.rP,  
  );  

  static Future<Worker> create(void Function(SendPort) entryPoint) async {  
    final rp = ReceivePort();  
    final isolate = await Isolate.spawn(  
      entryPoint,  
      rp.sendPort,  
    );  

    final sp = await rp.first as SendPort;  

    return Worker._(isolate, sp, rp);  
  }  
}  

// Handler for RemoteMessage events  
void _isolateEntryPoint(SendPort sendPort) {  
  final receivePort = ReceivePort();  
  sendPort.send(receivePort.sendPort);  

  receivePort.listen(  
    (message) async {  
      switch (message) {  
        case RemoteMessage():  
          try {  
            final res = await message.computation();  
            message.sendPort.send(res);  
            break;  
          } catch (e) {  
            message.sendPort.send(e);  
          }  
        default:  
          throw UnimplementedError();  
      }  
    },  
  );  
}  

// Handler for String events  
void _isolateEntryPoint2(SendPort sendPort) {  
  final receivePort = ReceivePort();  
  sendPort.send(receivePort.sendPort);  

  receivePort.listen(  
    (message) async {  
      switch (message) {  
        case String():  
          print(message);  
          break;  
        default:  
          throw UnimplementedError();  
      }  
    },  
  );  
}

Notice that all workers created via the static create method have different entry points (_isolateEntryPoint and _isolateEntryPoint2). Yet, the Worker class itself lacks additional methods for interaction. Let’s fix this with ET.

// Only for printing messages  
extension type PrintWorker(Worker worker) {  
  void print(String message) {  
    worker.sP.send("Isolate ${Isolate.current.hashCode}: $message");  
  }  
}  

// Only for heavy computations  
extension type ComputeWorker(Worker worker) {  
  Future<dynamic> compute(Future<dynamic> Function() computation) async {  
    final responsePort = ReceivePort();  
    worker.sP.send(RemoteMessage(  
      computation,  
      responsePort.sendPort,  
    ));  

    return await responsePort.first;  
  }  
}

The key idea is that the base Worker class hides the general isolate creation logic, while ET adds specialized methods that restrict interaction with the worker.

What does this give us in practice? If you create different workers for different tasks (e.g., one for logging and three for heavy computations) or even manage their lifecycle dynamically, this approach protects against errors when working with the worker’s public API, which is implemented using ET. The entire interaction API is centralized, not scattered across the code, and doesn’t require inheritance hierarchies. Additionally, the code becomes more expressive: compare worker.sendPort.send(() => 2 + 2) to computeWorker.compute(() => 2 + 2).

void main() async {  
  final w = PrintWorker(await Worker.create(_isolateEntryPoint2));  
  final w2 = ComputeWorker(await Worker.create(_isolateEntryPoint));  

  // Only use methods declared in the extension  
  w.print("Hello from isolate");  
  w.compute(...); // Error!  

  final result = await w2.compute(  
    () async => 2 + 2,  
  );  

  print("Computation res: $result");  
}

The results:

We’ve encapsulated all low-level control code, message formatting, and port-sending logic. Users only see semantically meaningful operations.
New worker types can be added without modifying the base Worker class.
Unlike implementing this via wrapper classes or inheritance, there’s no overhead (ET don’t create additional objects in memory). At runtime, PrintWorker disappears, leaving only the original Worker—but with compile-time safety guarantees.

Final thoughts

Extension types aren’t just another Dart feature — they’re a fundamentally new way to design abstractions. They offer something unattainable with either extension methods or classes: static type safety without runtime overhead.

Mastering extension types is another step toward professional Dart proficiency. Their use requires creativity, practice, and exposure, but once you find your first real-world use case, you’ll unlock a new level of expressiveness and control in your code.