Beyond Boilerplate: Transforming Data with Dart Records and Pattern Matching

When you need to return multiple values from a function or parse deeply nested data structures, Dart developers often fall into two suboptimal traps: creating a 'throwaway' class that exists only for transport, or using a Map<String, dynamic> which sacrifices type safety. Since Dart 3.0, the introduction of Records and Pattern Matching offers a third path: a declarative way to deconstruct data directly within your logic flow without the overhead of manual mapping.

The Power of Anonymous Records

Records are anonymous types that allow you to group multiple objects into one unit. Unlike classes, they don't require a formal definition, making them ideal for internal data transformations or returning multiple results from a function where the structure is unlikely to change across the codebase.

Consider a function that calculates a user's status. Before records, you might have defined a StatusResult class. With records, you simply define the signature:

// Using a record with named fields
(bool isActive, String lastLogin) checkUserStatus(int id) {
  if (id == 0) return (false, 'Never');
  return (true, 'Today');
}

Deconstructing Data with Switch Expressions

The real efficiency gain occurs when you combine records with switch expressions. Pattern matching allows you to "reach inside" a record or a list and extract variables instantly. This replaces multiple lines of manual assignment and if-else logic with a single, readable block.

In the example below, we process a complex API response represented as a nested record. We use switch expressions to handle different states, destructuring the data directly in the cases.

void processResponse((int code, Map data) response) {
  final message = switch response {
    (200, {'name': String name}) => 'Welcome, $name!',
    (404, _) => 'Resource not found',
    (500, var error) => 'Server error: $error',
    (var code, _) => 'Unexpected status: $code',
  };

  print(message);
}

In the code above, the (200, {'name': String name}) pattern does three things: it checks if the code is 200, verifies the map contains a key named 'name', and casts it to a String. If conditions aren't met, it falls through to the next pattern.

Refining Logic with Guards

Sometimes a type check isn't enough; you need logical filtering. The when guard clause allows you to inject boolean expressions directly into your patterns. This keeps your filtering logic coupled with your data extraction logic.

void evaluateDimensions((double width, double height) dimensions) {
  final orientation = switch dimensions {
    (var w, var h) when w == h && w > 100 => 'Large Square',
    (var w, var h) when w > h => 'Landscape',
    _ => 'Portrait',
  };
  print(orientation);
}

Trade-offs and Limitations

While records reduce boilerplate, they come with architectural costs. Because records are anonymous, they lack the semantic clarity of a class. If you are passing a record through multiple layers of your application, it becomes difficult for other developers to know what the fields represent without checking the implementation. In those cases, a class is still superior.

Additionally, exhaustiveness checking—where the compiler ensures you've handled every possible case—works best when using sealed classes or enums. If you are matching against generic types or records, you must always provide a default case (_) to avoid runtime errors.

Actionable Steps

To start using these features, ensure your environment is Dart 3.0 or higher by running dart --version. Begin by replacing simple "multiple return" classes with records, and observe how much conditional code you eliminate by replacing manual object mapping.