Flutter en Dart 3: Records, Patterns en Geavanceerde Sollicitatievragen

Dart 3 records, patterns en sealed classes vormen het fundament van moderne Flutter-ontwikkeling in 2026. Deze drie features, geïntroduceerd in Dart 3.0 en verfijnd tot Dart 3.11, maken algebraïsche datatypes, exhaustieve pattern matching en compile-time veiligheid mogelijk die hele categorieën bugs detecteert voordat ze runtime bereiken.

Dart 3 Records: Lichtgewicht Data-aggregatie

Records lossen een langdurig probleem in Dart op: het retourneren van meerdere waarden uit een functie zonder een dedicated class te maken. Een record is een anoniem, onveranderlijk, geaggregeerd type.

// Returning multiple values with a positional record
(String, int) parseUserInput(String raw) {
  final parts = raw.split(':');
  return (parts[0].trim(), int.parse(parts[1]));
}

// Named fields improve readability for complex returns
({String name, String email, bool isVerified}) fetchUserProfile(String id) {
  // Simulated database lookup
  return (
    name: 'Alice Chen',
    email: 'alice@example.com',
    isVerified: true,
  );
}

Records zijn structureel getypeerd: twee records met dezelfde veldtypen en -namen zijn hetzelfde type. Dit elimineert de noodzaak voor Tuple2, Pair of vergelijkbare utility-classes waar Flutter-ontwikkelaars vóór Dart 3 op vertrouwden.

// Structural equality — no need for custom == operator
void main() {
  final a = (1, 'hello');
  final b = (1, 'hello');
  print(a == b); // true — records compare by value

  // Named fields also support equality
  final profile1 = (name: 'Alice', role: 'admin');
  final profile2 = (name: 'Alice', role: 'admin');
  print(profile1 == profile2); // true
}

Records zijn het meest geschikt voor functie-retourwaarden, lokale aggregatie en map-keys. Voor domeinmodellen met methoden en validatie blijven classes de juiste keuze.

Dart Pattern Matching: Destructuring en Control Flow

Pattern matching in Dart 3 gaat ver voorbij eenvoudige typecontroles. Patterns destructureren waarden, binden variabelen en nemen deel aan control flow — allemaal in een enkele expressie.

// Destructuring a record with pattern matching
void main() {
  final (name, email, isVerified) = fetchUserProfile('u-123');
  // name, email, isVerified are now local variables

  // List patterns with rest operator
  final scores = [98, 87, 92, 76, 84];
  final [first, second, ...remaining] = scores;
  print('Top two: $first, $second'); // 98, 87
  print('Others: $remaining');        // [92, 76, 84]
}

Switch-expressies, gecombineerd met patterns, vervangen uitgebreide if-else-ketens door beknopte, exhaustieve matching:

// Switch expression with guard clauses
String classifyScore(int score) => switch (score) {
  >= 90 => 'Excellent',
  >= 80 => 'Good',
  >= 70 => 'Average',
  >= 60 => 'Below Average',
  _ => 'Needs Improvement',
};

// Object pattern matching with type checking
String describeValue(Object value) => switch (value) {
  int n when n < 0   => 'Negative integer: $n',
  int n              => 'Positive integer: $n',
  String s when s.isEmpty => 'Empty string',
  String s           => 'String of length ${s.length}',
  List l when l.isEmpty  => 'Empty list',
  List l             => 'List with ${l.length} elements',
  _                  => 'Unknown type',
};

Guard-clausules (het when-keyword) voegen conditionele logica toe aan patterns zonder nesting. Dit houdt switch-expressies plat en leesbaar.

Sealed Classes: Exhaustieve State-modellering

Sealed classes beperken hun subtype-hiërarchie tot hetzelfde bestand, waardoor de Dart-compiler kan verifiëren dat elk subtype wordt afgehandeld in een switch. Dit is het cruciale element voor type-safe state management.

// Sealed class defining all possible authentication states
sealed class AuthState {}

class AuthInitial extends AuthState {}

class AuthLoading extends AuthState {}

class AuthAuthenticated extends AuthState {
  final String userId;
  final String displayName;
  AuthAuthenticated({required this.userId, required this.displayName});
}

class AuthError extends AuthState {
  final String message;
  final int? statusCode;
  AuthError({required this.message, this.statusCode});
}

De compiler dwingt exhaustiviteit af — elke subclass moet worden afgehandeld:

// Exhaustive switch — compiler error if a case is missing
Widget buildAuthUI(AuthState state) => switch (state) {
  AuthInitial()       => const LoginPrompt(),
  AuthLoading()       => const CircularProgressIndicator(),
  AuthAuthenticated(
    displayName: final name
  )                   => Text('Welcome, $name'),
  AuthError(
    message: final msg,
    statusCode: final code,
  )                   => ErrorBanner(
    message: msg,
    code: code,
  ),
};

Het toevoegen van een nieuw AuthState-subtype (bijv. AuthSessionExpired) produceert onmiddellijk compile-time fouten op elke plek die AuthState afhandelt. Dit elimineert het risico van vergeten state-afhandeling — een veelvoorkomende bron van bugs in Flutter-apps met string- of enum-gebaseerde state.

Records, Patterns en Sealed Classes Combineren in Flutter

De werkelijke kracht komt naar voren wanneer deze drie features samenwerken. Een beproefd patroon voor Flutter API-aanroepen combineert sealed classes voor resultaattypen met records voor gestructureerde data:

// Generic sealed result type for API operations
sealed class ApiResult<T> {}

class ApiSuccess<T> extends ApiResult<T> {
  final T data;
  final ({int statusCode, Map<String, String> headers}) metadata;
  ApiSuccess(this.data, {required this.metadata});
}

class ApiFailure<T> extends ApiResult<T> {
  final String error;
  final int? statusCode;
  ApiFailure(this.error, {this.statusCode});
}

// Consuming the sealed result with pattern matching
Widget buildProductList(ApiResult<List<Product>> result) => switch (result) {
  ApiSuccess(
    data: final products,
    metadata: (statusCode: 200, headers: _),
  ) when products.isNotEmpty => ListView.builder(
    itemCount: products.length,
    itemBuilder: (_, i) => ProductCard(products[i]),
  ),
  ApiSuccess(data: final products) when products.isEmpty =>
    const EmptyState(message: 'No products found'),
  ApiFailure(statusCode: 401) =>
    const AuthExpiredBanner(),
  ApiFailure(error: final msg) =>
    ErrorDisplay(message: msg),
};

Dit patroon elimineert null-checks, type-casts en runtime-assertions. Elke mogelijke state wordt op compile-time verantwoord.

Geavanceerde Sollicitatievragen over Dart 3 Features

Technische sollicitatiegesprekken voor Flutter-posities in 2026 testen steeds vaker het begrip van Dart 3 taalfeatures. Hieronder staan vragen die verder gaan dan syntax en architectureel denken onderzoeken.

V: Hoe verschillen records van classes bij datamodellering?

Records zijn structureel getypeerd, onveranderlijk en anoniem. Twee records met identieke veldtypen zijn hetzelfde type. Classes zijn nominaal getypeerd — twee classes met identieke velden zijn verschillende typen. Records zijn geschikt voor functie-retourwaarden, lokale aggregatie en map-keys. Classes zijn geschikt voor domeinmodellen die methoden, validatie of identiteit vereisen.

V: Wanneer heeft een sealed class-hiërarchie de voorkeur boven een enum?

Enums dragen geen variant-specifieke data. Sealed classes staan elk subtype toe om verschillende velden te bevatten. Bijvoorbeeld, AuthAuthenticated bevat userId terwijl AuthError message en statusCode bevat. Enums kunnen dit niet modelleren. Sealed classes ondersteunen bovendien diep pattern matching op hun velden, niet alleen op de variantnaam.

V: Wat gebeurt er op compile-time wanneer een nieuw subtype aan een sealed class wordt toegevoegd?

De Dart-analyzer markeert onmiddellijk elke switch-expressie of -statement die dat sealed type afhandelt als niet-exhaustief. De code compileert niet totdat het nieuwe geval overal is afgehandeld. Deze compile-time garantie is het belangrijkste voordeel ten opzichte van abstracte classes, die geen exhaustiviteitscontrole bieden.

V: Hoe verbetert pattern matching null safety in de praktijk?

Patterns maken beknopte null-controles mogelijk via if-case:

// If-case for null-safe extraction
void processUser(Map<String, dynamic> json) {
  if (json case {'name': String name, 'age': int age}) {
    // name and age are non-nullable here
    print('$name is $age years old');
  } else {
    print('Invalid user data');
  }
}

Het pattern valideert gelijktijdig de mapstructuur, controleert typen en bindt non-nullable variabelen. Zonder patterns vereist dit geneste null-checks en handmatige type-casts.

V: Leg het verschil uit tussen _ in patterns en _ als wildcard-variabele (Dart 3.7+).

Vóór Dart 3.7 was _ alleen een wildcard binnen patterns — var [_, _, third] = list werkte omdat pattern-_ nooit bindt. Buiten patterns was _ een reguliere variabelenaam. Dart 3.7 heeft dit geünificeerd: _ is nu overal non-binding, inclusief functieparameters en lokale variabelen. Meerdere _-declaraties in dezelfde scope veroorzaken geen conflicten meer.

Migratiestrategie: Dart 3 Features Adopteren in Bestaande Flutter-Apps

Het migreren van een bestaande Flutter-codebase naar Dart 3 patterns kan incrementeel plaatsvinden. Het is aan te raden te beginnen met de wijzigingen met de hoogste waarde.

Stap 1 — Tuple/Pair-typen vervangen door records. Zoek naar Tuple2, Pair of aangepaste twee-veld classes die uitsluitend worden gebruikt voor het bundelen van retourwaarden. Vervanging door records leidt tot directe codereductie.

Stap 2 — If-else typecontroles omzetten naar switch-expressies. Elke keten van if (value is TypeA) ... else if (value is TypeB) wordt een switch-expressie met pattern matching. Dit geldt vooral voor widget-constructie en state-afhandeling.

Stap 3 — State-hiërarchieën verzegelen. Voor BLoC-states, Riverpod notifier-states of aangepaste state-classes het sealed-modifier toevoegen. De compiler identificeert vervolgens elke locatie waar state-afhandeling onvolledig is.

Stap 4 — Guard-clausules in switches adopteren. if-controles binnen case-bodies vervangen door when-guards voor plattere, beter leesbare control flow.

Elke stap is onafhankelijk waardevol en vereist niet dat de hele codebase in één keer wordt aangepast.

Conclusie

• Records elimineren boilerplate voor multi-value retourwaarden — gebruik ze in plaats van Tuple, Pair of single-purpose classes
• Pattern matching vervangt if-else typecontrole-ketens door exhaustieve, compiler-geverifieerde switch-expressies
• Sealed classes garanderen dat elke state-variant wordt afgehandeld, waardoor runtime-bugs worden omgezet in compile-time fouten
• Guard-clausules (when) houden switch-expressies plat en elimineren geneste conditionelen binnen case-bodies
• Dart 3.7 wildcard-variabelen (_) unificeren het non-binding gedrag van patterns met reguliere parameters en lokale variabelen
• Migratie kan incrementeel plaatsvinden: begin met records voor functie-retourwaarden, converteer vervolgens typecontroles naar switches, verzegel daarna state-hiërarchieën
• Deze features worden actief getest in Flutter technische sollicitatiegesprekken — begrip van het "waarom" is even belangrijk als de syntax