DEV Community: Dom Jocubeit

Software Bill of Materials (SBOM) and Flutter Apps

Dom Jocubeit — Sun, 30 Jul 2023 05:09:40 +0000

In my last article, Flutter Takes a Leap Towards Enhanced Security with SLSA Compliance, we touched on the Software Bill of Materials (SBOM) and how Google has achieved Supply Chain Levels for Software Artifacts (SLSA) Level 1 for Flutter.

With the ability to build performant native-compiled applications for desktops on Windows, Mac, and Linux leveraging a single codebase and access to native functionality with full access to the underlying Win32, Cocoa, or UNIX platform APIs; we will see enterprise desktop applications being built in Flutter and Dart.

In this article, I want to delve deeper into the SBOM and its relevance to Flutter apps and Dart packages, particularly to this market segment.

The Evolution of SBOM

The concept of SBOM can be traced back to the late 1990s when the Open Source Software (OSS) movement gained momentum. As software ecosystems expanded, so did the usage of third-party dependencies, which brought challenges of security vulnerabilities and license compliance.

To address these concerns, the National Telecommunications and Information Administration (NTIA) introduced SBOM in 2019. The idea was to create a standardised way to document a software project's components and their origins, allowing for improved security, risk management, and supply chain visibility.

The Significance of SBOM

In the enterprise environment, desktop applications are critical tools that facilitate business processes, streamline operations, and improve productivity. However, as these applications become more complex and interconnected, managing security, license compliance, and supply chain transparency become increasingly challenging.

This is where the Software Bill of Materials (SBOM) emerges as a powerful and indispensable asset for enterprise desktop applications, especially when developed using technologies like Flutter and Dart packages. Let's explore how SBOM empowers enterprise developers and stakeholders:

Enhanced Security

Security breaches and cyber-attacks pose significant risks to enterprise data and operations. The use of third-party dependencies in desktop applications increases the attack surface, potentially exposing vulnerabilities that malicious actors can exploit. By adopting SBOM, enterprises gain greater visibility into the software components used in their applications, allowing them to perform comprehensive security assessments.

With SBOM, developers can identify known vulnerabilities in the third-party packages they utilise. Armed with this knowledge, they can quickly prioritise and apply security patches, reducing the window of exposure and strengthening the application's overall security posture. Enterprises can also leverage SBOM to assess the security profiles of potential software vendors, ensuring that their desktop applications come from trusted sources.

License Compliance

Compliance with open-source licenses is a vital aspect of enterprise software development. Non-compliance can lead to legal challenges, financial penalties, and damage to an organisation's reputation. SBOM enables developers to maintain a precise record of the licenses associated with each software component in their desktop applications.

With this comprehensive license inventory, enterprises can easily identify license conflicts or potential violations and take the necessary steps to remedy the situation. SBOM empowers organisations to make informed decisions about the open-source packages they include in their applications, ensuring that the licenses align with their business goals and legal requirements.

Supply Chain Transparency

For enterprise desktop applications, understanding the supply chain of software components is crucial. The use of third-party dependencies introduces a chain of interconnected packages, and vulnerabilities in one component can cascade to affect the entire application. SBOM provides transparency into this intricate web of dependencies.

With SBOM, enterprises can trace the origins of each component used in their desktop applications, verifying the authenticity and integrity of the software supply chain. This information empowers stakeholders to make informed decisions about the risk associated with specific dependencies, leading to better-informed development practices and mitigating potential security and compliance issues.

Streamlined Vendor Management

Enterprise desktop applications often involve collaboration with external vendors or development teams. The adoption of SBOM in the development process streamlines vendor management by providing a clear view of the software components introduced by each party.

By exchanging SBOM data with vendors, enterprises can assess the security and compliance risks associated with third-party contributions effectively. This proactive approach fosters better collaboration and facilitates smoother integration of vendor code into the final desktop application, leading to a more robust and secure end product.

Where SBOM may be Mandatory?

SBOM has become increasingly mandatory in various sectors, especially in government, military, and industries where security, compliance, and transparency are of utmost importance. he White House Office of Management and Budget last month gave federal agencies a year to collect software attestations and artefacts like SBOMs from government software vendors verifying adherence to secure development practices. Let's take a look at some examples of where SBOM is or will become mandatory:

Government Agencies and Contractors

Government agencies at the local, state, and federal levels often deal with sensitive data and critical systems. To ensure the security and integrity of their software infrastructure, these agencies may mandate the use of SBOM. SBOM enables government bodies to assess the risk associated with the software components they use, facilitating better decision-making and ensuring compliance with security standards and regulations.

Defence and Military Organisations

In the defence and military sectors, security is paramount. Any vulnerability or compromise in the software systems used for defence applications could have severe consequences. SBOM becomes mandatory in these industries to maintain a clear inventory of software components and their security profiles. It allows defence organisations to assess the supply chain of their software, detect potential threats, and respond proactively to security incidents.

Healthcare and Medical Devices

In the healthcare industry, the safety and privacy of patient data are critical concerns. For medical devices and healthcare software, regulatory bodies such as the U.S. Food and Drug Administration (FDA) require manufacturers to provide an SBOM. This allows regulators and stakeholders to assess the security and compliance aspects of medical devices, ensuring patient safety and protecting sensitive medical information.

Financial Services

Financial institutions handle vast amounts of sensitive customer data and transactions. To maintain regulatory compliance and secure their systems against potential cyber threats, financial organisations may enforce SBOM practices. SBOM helps financial institutions evaluate the security posture of their applications, including third-party components, ensuring a robust and resilient software environment.

Critical Infrastructure and Utilities

Industries operating critical infrastructure, such as energy, transportation, and utilities, are prime targets for cyber-attacks. SBOM plays a vital role in these sectors to identify and address security vulnerabilities in software systems that control critical operations. By implementing SBOM, these industries can enhance their cybersecurity strategies and safeguard against potential disruptions.

Aerospace and Aviation

The aerospace and aviation industries rely heavily on complex software systems to operate aircraft and manage air traffic. To ensure the safety of passengers and air transportation, SBOM may be required to identify potential risks in the software used for flight controls, navigation, and communication systems.

SBOM for Flutter and Dart

Flutter, Google's UI toolkit, has rapidly gained popularity in the development of cross-platform applications. As Flutter apps often rely on numerous third-party packages, managing their security and licensing aspects can be challenging. Integrating SBOM into Flutter projects empowers developers to mitigate risks effectively.

SPDX Format and its Relevance

SPDX (Software Package Data Exchange) is an industry-standard format for describing and sharing SBOM information. It provides a standardised way to document software components, licenses, and copyright information. The use of the SPDX format ensures consistency and interoperability between different tools and platforms, streamlining SBOM sharing and analysis.

Utilising the SBOM Package for Flutter and Dart

The sbom package available on pub.dev is a valuable resource for Flutter developers seeking to generate SBOM SPDX files seamlessly. The SBOM is generated from the Dart files contained in the package plus and the pubspec.yaml. Generation is controlled by a configuration file named sbom.yaml which must be present in the top-level directory of the package. The configuration file allows the setting of the SBOM format, generation directives and field overrides. Overrides can be found in the example directory when viewing the source code on GitHub. Generation is effectively a merge of any field overrides in this file and data generated from the package environment and its pubspec file. Currently, only the Software Package Data Exchange (SPDX) format is supported at specification version 2.2, but support for other SBOM format types such as CycloneDX and SWID will be added in future releases.

Adding the sbom.yaml is as easy as including the following in your package root:

type: spdx

spdx:
  SPDXFormat: 'tagvalue'

Add the sbom executable to the global path:

% dart pub global activate sbom

Resolving dependencies... (1.1s)
+ args 2.4.2
+ collection 1.18.0
+ crypto 3.0.3
+ meta 1.9.1
+ path 1.8.3
+ pub_cache 0.3.2
+ pub_semver 2.1.4
+ sbom 2.0.0
+ source_span 1.10.0
+ string_scanner 1.2.0
+ term_glyph 1.2.1
+ typed_data 1.3.2
+ yaml 3.1.2
Building package executables...
Built sbom:sbom.
Installed executable sbom.
Activated sbom 2.0.0.

Now execute the sbom command in the package root directory:

% sbom

SBOM generator for Dart packages
Parsing SBOM configuration file
Generating the SBOM
SBOM type is SPDX
SBOM generation complete

The generator will create a new file called sbom.spdx.

Full Transparency

The Dart sbom generator only generates the SPDX for your package. It doesn't recursively generate SBOMs for every dependency and their dependencies, etc. To provide a fully transparent bill of materials for an application, the SBOM package could be improved to perform this for every dependency, currently, this would have to be done manually.

What Have We Learned?

In sectors where security, compliance, and transparency are paramount, the use of SBOM has become mandatory. Government agencies, military organisations, healthcare providers, financial institutions, critical infrastructure operators, and aerospace and aviation industries all benefit from SBOM's ability to enhance software security, ensure license compliance, and provide supply chain transparency. As software development continues to evolve, SBOM will continue to be an essential tool in safeguarding critical systems and protecting against cybersecurity threats across various sectors.

For enterprise desktop applications developed using Flutter and Dart packages, SBOM becomes a game-changing asset, empowering organisations to create secure, compliant, and transparent software systems. The enhanced security, license compliance, and supply chain transparency that SBOM offers are instrumental in safeguarding sensitive data, mitigating risks and maintaining customers' trust.

By embracing SBOM as a best practice, enterprises can effectively manage the complexities of modern software development, strengthen their software supply chains, and build resilient desktop applications that stand up to the rigorous demands of the business landscape. In the ever-evolving world of technology and cybersecurity, SBOM stands as a reliable tool to empower enterprises with the knowledge and insight needed to stay ahead of potential threats and challenges and increase an organisation's security posture.

Other Information

This articles was originally posted on my personal blog at https://dom.jocubeit.com/software-bill-of-materials-sbom-and-flutter-apps

Flutter Takes a Leap Towards Enhanced Security with SLSA Compliance

Dom Jocubeit — Sun, 23 Jul 2023 00:00:00 +0000

Flutter 3.10 ships with SLSA Level 1 compliance

In the fast-paced digital world, ensuring the security and integrity of software is of paramount importance. With the increasing frequency and sophistication of cyber-attacks, developers and organisations are continually seeking ways to bolster their security practices. In this pursuit, the Software Bill of Materials (SBOM) has emerged as a crucial framework for promoting transparency and accountability in the software supply chain. Recently, Flutter, Google's popular open-source UI software development toolkit, announced its new compliance with the Supply chain Levels for Software Artifacts (SLSA), marking a significant milestone in enhancing the security posture of Flutter apps.

What is SLSA?

SLSA, which stands for Supply chain Levels for Software Artifacts, is a framework developed by Google to establish a set of security requirements and best practices for software supply chains. It is designed to create a transparent and robust software supply chain ecosystem, safeguarding software components from potential security threats. SLSA has multiple levels, each representing an increasing level of security rigour.

SLSA Level 1: The first level focuses on establishing a strong foundation for security. It requires the use of a formalised Bill of Materials, ensuring that all components in the supply chain are listed. Additionally, it enforces that the software is built with well-defined and reproducible build processes.
SLSA Level 2: Level 2 builds upon the foundations laid in Level 1 and introduces stricter security measures. At this level, software suppliers are required to cryptographically sign the provenance of each software artifact in the supply chain. This cryptographic signing enables consumers to verify the authenticity and integrity of the artifacts they receive, reducing the risk of tampering or unauthorised modifications during distribution.
SLSA Level 3: Level 3 further enhances security by enforcing the principle of "defence-in-depth." It requires the adoption of hardware-based security measures, such as hardware-backed cryptographic signing and verification. Hardware security mechanisms provide an additional layer of protection against attacks, making it significantly more challenging for adversaries to compromise the software supply chain.

Flutter's Journey to SLSA Compliance

Flutter has emerged as one of the leading frameworks for building high-quality, cross-platform applications. With its ever-growing popularity, the Flutter team recognised the need to fortify its security practices to inspire even greater confidence among developers and end-users.

The journey to achieve SLSA compliance was a collaborative effort involving the Flutter development team, the broader open-source community, and security experts. The process commenced with a comprehensive audit of Flutter's supply chain, identifying potential areas of improvement and addressing any vulnerabilities.

One of the core components of SLSA is the implementation of a Software Bill of Materials (SBOM). Flutter tackled this requirement by creating a structured and standardised SBOM that lists all the software components and dependencies used in the framework. This SBOM acts as a critical reference point for developers and users to understand the software's composition and any potential security implications.

To achieve higher levels of SLSA compliance, Flutter had to introduce additional security measures. This involved implementing cryptographic signing of software artifacts at Level 2 and adopting hardware-based security mechanisms at Level 3. These measures significantly reduce the risk of supply chain attacks and ensure that software consumers can trust the authenticity and integrity of the artifacts they receive.

Benefits of Flutter's SLSA Compliance

Flutter's compliance with SLSA brings forth numerous benefits for developers, organisations, and end-users alike:

Enhanced Security: SLSA compliance ensures that Flutter apps are built with robust security practices, safeguarding users from potential threats and vulnerabilities.
Trust and Transparency: By adhering to SLSA's principles, Flutter provides transparency into its supply chain, building trust among developers and users.
Reduced Risk of Supply Chain Attacks: The cryptographic signing of artifacts and hardware-based security mechanisms make it exceedingly difficult for malicious actors to tamper with Flutter's software components.
Industry Leadership: Flutter's commitment to SLSA compliance sets an example for other software projects, encouraging the industry to prioritise security in software development.
Future-Proofing: As software security threats evolve, SLSA compliance ensures that Flutter remains resilient against emerging challenges.

Conclusion

Flutter's compliance with SLSA is a significant achievement that demonstrates its dedication to improving the security of its software supply chain. By embracing the SLSA framework, Flutter takes a proactive approach to fortifying its software against potential attacks, ensuring that its vast community of developers can build and deploy applications with greater confidence. As the digital landscape continues to evolve, initiatives like SLSA become increasingly vital to creating a secure and trustworthy software ecosystem.

Flutter's commitment to security sets a strong example for other software projects, encouraging the broader tech industry to prioritise security at every step of the development process. With SLSA compliance now in place, Flutter is undoubtedly positioned to deliver even more secure and reliable experiences for its users; especially considering they indicated they wanted to pursue Level 2 back in March 2023 in their article about achieving Level 3 compliance in the Cocoon engine.

About the image

The poster image was created using Fotor.com's AI image generator. It's an original image representing bad actors or cyber criminals.

About the article

This post originally appears on my personal web site at https://dom.jocubeit.com/flutter-takes-a-leap-towards-enhanced-security-with-slsa-compliance

Exploring Dart 3.0’s New Class Modifiers with Real-World Examples

Dom Jocubeit — Wed, 19 Jul 2023 11:00:00 +0000

Dart 3.0 introduces a set of powerful class modifiers that provide developers with more control over inheritance, implementation, and type hierarchy. These modifiers, namely base, interface, final, and sealed, complement the existing modifiers abstract and mixin to offer distinct guarantees and restrictions when applied to classes or mixins.

In this article, we will delve into these modifiers using real-world object examples, showcasing their practical applications and benefits.

The base Modifier

The base modifier ensures the enforcement of inheritance and implementation within a class or mixin's own library. It offers several guarantees such as:

The base class constructor is invoked whenever an instance of a subtype is created.
All private members implemented in the base class are inherited by subtypes.
The addition of newly implemented members in the base class does not break existing subtypes unless a subtype already declares a member with the same name and incompatible signature.

To illustrate this, let’s consider the example of a Vehicle class defined in the library base_vehicle.dart. The base modifier is applied to ensure that the Vehicle class is extended within its own library, disallowing implementation outside of it.

// Library base_vehicle.dart
base class Vehicle {
  void moveForward(int meters) {
    // ...
  }
}

// Library test.dart
import 'base_vehicle.dart';

// Example usage
Vehicle myVehicle = Vehicle(); // Can be constructed

base class Car extends Vehicle {
  int passengers = 4;
  // ...
}

// ERROR: Cannot be implemented
base class Truck implements Vehicle {
  @override
  void moveForward() {
    // ...
  }
}

The interface Modifier

With the interface modifier, developers can define interfaces in Dart. These interfaces can be implemented by libraries outside their defining library but cannot be extended. The key guarantees provided by the interface modifier are:

Instance methods within the interface always invoke known implementations from the same library.
Other libraries cannot override methods in a way that could cause unexpected behaviour within the interface class.

Let’s consider an example where a Vehicle interface is defined in vehicle_interface.dart and implemented in another library, test.dart.

// Library vehicle_interface.dart
interface class Vehicle {
  void moveForward(int meters) {
    // ...
  }
}

// Library test.dart
import 'vehicle_interface.dart';

// Example usage
Vehicle myVehicle = Vehicle(); // Can be constructed

// ERROR: Cannot be inherited
class Car extends Vehicle {
  int passengers = 4;
  // ...
}

// Can be implemented
class Truck implements Vehicle {
  @override
  void moveForward(int meters) {
    // ...
  }
}

The final Modifier

The final modifier closes the type hierarchy, preventing subtyping from external classes. It disallows both inheritance and implementation, ensuring that the API remains stable and instance methods are not overwritten by third-party subclasses. However, final classes can still be extended or implemented within the same library. It is worth noting that the final modifier encompasses the effects of the base modifier, requiring any subclasses to be marked as base, final, or sealed.

Consider the following example where a final Vehicle class is defined in final_vehicle.dart, and its usage is demonstrated in test.dart:

// Library final_vehicle.dart
final class Vehicle {
  void moveForward(int meters) {
    // ...
  }
}

// Library test.dart
import 'final_vehicle.dart';

// Example usage
Vehicle myVehicle = Vehicle(); // Can be constructed

// ERROR: Cannot be inherited
class Car extends Vehicle {
  int passengers = 4;
  // ...
}

class Truck implements Vehicle {
  // ERROR: Cannot be implemented
  @override
  void moveForward(int meters) {
    // ...
  }
}

The sealed Modifier

The sealed modifier allows developers to create a known and enumerable set of subtypes, ensuring exhaustive handling through switch statements. Sealed classes cannot be extended or implemented outside their defining library but can have factory constructors and define constructors for their subclasses. Subclasses of sealed classes, however, are not implicitly abstract.

Let’s explore a practical example of a sealed Vehicle class with several subclasses:

sealed class Vehicle {}

class Car extends Vehicle {}

class Truck implements Vehicle {}

class Bicycle extends Vehicle {}

// ERROR: Cannot be instantiated
Vehicle myVehicle = Vehicle();

// Subclasses can be instantiated
Vehicle myCar = Car();

String getVehicleSound(Vehicle vehicle) {
  // ERROR: The switch is missing the Bicycle subtype or a default case.
  return switch (vehicle) {
    Car() => 'vroom',
    Truck() => 'VROOOOMM',
  };
}

What have we learned?

Dart 3.0’s new class modifiers, including base, interface, final, and sealed, will empower developers to design more robust and maintainable code. By using real-world examples, we have demonstrated how these modifiers offer practical solutions for enforcing inheritance, implementing interfaces, closing the type hierarchy, and ensuring exhaustive handling of subtypes. Incorporating these modifiers into your Dart projects will enhance code clarity, prevent unexpected behaviours, and contribute to overall code quality and reliability.

Other information

This post originally appears on my personal web site at https://dom.jocubeit.com/exploring-dart-30s-new-class-modifiers-with-real-world-examples

I used another free credit at STOCKIMG.AI to generate a horizontal poster using disco diffusion for the article poster image. This time I used the image from my second post as the primer, with some words about class modifiers, inheritance, type hierarchy and interfaces. The image above is the generated result. Again, I was expecting something similar to the second image and the result didn’t disappoint. With all three articles being in the same vein, I decided to use it.

Exploring Dart 3.0's Powerful Pattern Matching and Destructuring

Dom Jocubeit — Thu, 13 Jul 2023 14:33:11 +0000

Dart is a versatile programming language and has introduced new features that enhance code expressiveness and development productivity. Among these features, pattern matching and destructuring stand out as powerful tools. In this article, we'll delve into the world of patterns in Dart, exploring their various use cases and showcasing real-world examples.

Patterns in Dart: Matching Values and Destructuring Objects

Patterns are a syntactic category in Dart, representing the shape of a set of values that can be matched against actual values. They serve two main purposes: pattern matching and pattern destructuring.

Pattern Matching

Pattern matching enables developers to test whether a value meets specific criteria, such as having a particular shape, being a constant, equaling something else, or having a specific type. Let's look at some real-world examples:

Matching a Shape:

import 'dart:math';

class Rectangle { 
  final double width; 
  final double height; 

  Rectangle({required this.width, required this.height}); 
}

class Hexagon {
  final double sideLength;

  Hexagon({required this.sideLength});
}

void calculateArea(dynamic shape) { 
  switch(shape) {
    case Rectangle(width: double w, height: double h):
      final area = w * h;
      print('Area: $area');
      break;
    case Hexagon(sideLength: double l):
      final area = (3 * sqrt(3) * pow(l, 2)) / 2;
      print('Area: $area');
      break;
  }
}

void main() { 
  calculateArea(Rectangle(width: 5, height: 10)); // Area: 50 
  calculateArea(Hexagon(sideLength: 6.9)); // Area: 123.6944084225314
}

Matching a Constant:

const String example = 'example.com';
const String gmail = 'gmail.com';

void validateEmail(String email) {
  final pattern = RegExp(r'^[\w-]+@([\w-]+\.)+[\w-]+$');
  final match = pattern.firstMatch(email);

  if (match != null) {
    final domain = match.group(1);
    switch (domain) {
      case example:
        print('Valid email from example.com');
        break;
      case gmail:
        print('Valid email from gmail.com');
        break;
      default:
        print('Valid email from another domain');
    }
  } else {
    print('Invalid email format');
  }
}

void main() {
  validateEmail('john.doe@example.com'); // Output: Valid email from example.com
  validateEmail('jane.smith@gmail.com'); // Output: Valid email from gmail.com
  validateEmail('foo@bar.com'); // Output: Valid email from another domain
  validateEmail('invalid_email'); // Output: Invalid email format
}

Pattern Destructuring

Pattern destructuring provides a convenient way to break down an object into its constituent parts, extracting values for further use. Let's explore some practical scenarios:

Destructuring a List:

void processCoordinates(List<double> coordinates) {
  var [x, y, z] = coordinates;
  print('x: $x, y: $y, z: $z');
}

void main() {
  processCoordinates([10.5, 20.3, 5.1]); // Output: x: 10.5, y: 20.3, z: 5.1
}

Destructuring a Map Entry:

void processUser(MapEntry<String, int> userEntry) {
  var {key: username, value: age} = userEntry;
  print('Username: $username, Age: $age');
}

void main() {
  var user = MapEntry('JohnDoe', 25);
  processUser(user); // Output: Username: JohnDoe, Age: 25
}

Common Use Cases for Patterns in Dart

Simplifying Data Validation: Patterns prove valuable when validating complex data structures like JSON. They allow us to check if the structure conforms to our expectations and extract specific values effortlessly.
Enhancing Switch Statements: Switch statements become more powerful with pattern matching, enabling multiple cases to share a body or matching against various patterns to execute specific code blocks based on input conditions.
Efficient Variable Assignment: Patterns provide a concise and expressive way to declare and assign variables simultaneously, making code more readable and reducing redundancy.

What have we learned?

With pattern matching and destructuring, Dart empowers developers to write more expressive and concise code. Whether you're validating data, manipulating objects, or enhancing control flow, patterns offer a powerful and flexible toolset. By leveraging these features, you can improve your Dart programming skills and boost productivity in real-world scenarios.

Other information

I used another free credit at STOCKIMG.AI to generate a horizontal poster using disco diffusion for the article poster image. This time I used the image from my first post as the primer, with some words about pattern matching and destructuring. The image above is the generated result. This time I was expecting something similar and result is interesting. Given the two article topics are similar, I thought Id go ahead and use it.

Replacing tuples with records

Dom Jocubeit — Mon, 03 Jul 2023 11:40:00 +0000

A refactoring use-case for dart’s new language feature

With the release of Dart 3.0 came a new feature — records. You can learn about records in the Dart language documentation.

For those unaware, to paraphrase: records are an anonymous, immutable, aggregate type. Records let you bundle multiple objects into a single object, but unlike other collection types, records are fixed-sized, heterogeneous, and typed. Records are real values; you can store them in variables, nest them, pass them to and from functions, and store them in data structures such as lists, maps, and sets.

A practical use-case

I had an occasion to use the new records feature in updating a widget. I thought I’d share where the records feature works and the benefits gained.

The widget is not important, but for reference, it’s a table. The table has an undo feature for changes to rows.

In the original version, a tuple (package:tuple) with five dimensions was used to record the nature and details of a change to a row permitting a user to reverse the change if necessary. The tuples are stored on a stack, so undo is simply a matter of calling stack.pop(). The old code looked something like this:

import 'package:stack/stack.dart';
import 'package:tuple/tuple.dart';

enum UndoAction {
  created,
  updated,
  deleted,
  reordered,
}

class UndoState {
  // undo action, old state, new state, old index, new index
  final state = Stack<Tuple5<UndoAction, RowState?, RowState?, int?, int?>>();
}

An example of creating a tuple and adding it to the stack looks something like this:

import 'package:tuple/tuple.dart';

  ...
  onReorder: (oldIndex, newIndex) {
    setState(() {
      final tuple = Tuple(
        UndoAction.reordered, // undo action
        _tableSource.rows[newIndex], // old state
        null, // new state (n/a)
        oldIndex, // old index
        newIndex, // new index
      );

      _tableSource.undo.state.push(tuple);
      ...
    });
  }
  ...

Notice the comments on each element to imbue its semantics.

Even worse is accessing the elements of the tuple:

void _undoRow() {
  if (_tableSource.undo.state.isNotEmpty) {
    setState(() {
      // Retrieve the last action and delete it from the stack
      final lastAction = _tableSource.undo.state.pop();

      // Undo the last action
      switch (lastAction.item1) {
        ...
        case UndoAction.reordered:
          final rowState = lastAction.item2!;
          final oldIndex = lastAction.item4!;
          final newIndex = lastAction.item5!;
          _tableSource.rows.removeAt(newIndex);
          _tableSource.rows.insert(oldIndex, rowState);
          break;
        ...
      }
    });
    ...
  }
}

The elements have to be accessed using the itemN syntax. It's very unclear what the element represents in the structure, so appropriately named variables are required here.

Replacing with records

A simple swap in replacement of the tuple with a record looks like the following:

import 'package:stack/stack.dart';

enum UndoAction {
  created,
  updated,
  deleted,
  reordered,
}

final state = Stack<(UndoAction, RowState?, RowState?, int?, int?)>();

We immediately remove the need for the tuple package, so that can go.

And using it looks like this:

  ...
  onReorder: (oldIndex, newIndex) {
    setState(() {
      final undoRecord = (
        UndoAction.reordered, // undo action
        _tableSource.rows[newIndex], // old state
        null, // new state (n/a)
        oldIndex, // old index
        newIndex, // new index
      );

      _tableSource.undo.state.push(undoRecord);
      ...
    });
  }
  ...

And accessing the record fields is as follows:

void _undoRow() {
  if (_tableSource.undo.state.isNotEmpty) {
    setState(() {
      // Retrieve the last action and delete it from the stack
      final lastAction = _tableSource.undo.state.pop();

      // Undo the last action
      switch (lastAction.$1) {
        ...
        case UndoAction.reordered:
          final rowState = lastAction.$2!;
          final oldIndex = lastAction.$4!;
          final newIndex = lastAction.$5!;
          _tableSource.rows.removeAt(newIndex);
          _tableSource.rows.insert(oldIndex, rowState);
          break;
        ...
      }
    });
    ...
  }
}

Now we access the fields of the record using the $n syntax.

Have we swapped out one evil for another? Not quite, we did remove a dependency remember?

Where records shine

Records have a compelling feature — named fields. We can name the fields, and then access them using their field names.

Here is the updated code using named fields:

import 'package:stack/stack.dart';

enum UndoAction {
  created,
  updated,
  deleted,
  reordered,
}

class UndoState {
  final state = Stack<
      ({
        UndoAction undoAction,
        RowState? oldState,
        RowState? newState,
        int? oldIndex,
        int? newIndex,
      })>();
}

An example of creating a record and adding it to the stack now looks something like this:

  ...
  onReorder: (oldIndex, newIndex) {
    setState(() {
      final undoRecord = (
        undoAction: UndoAction.reordered,
        oldState: _tableSource.rows[newIndex],
        newState: null,
        oldIndex: oldIndex,
        newIndex: newIndex,
      );

      _tableSource.undo.state.push(undoRecord);
      ...
    });
  }
  ...

And accessing the fields is as follows:

void _undoRow() {
  if (_tableSource.undo.state.isNotEmpty) {
    setState(() {
      // Retrieve the last action and delete it from the stack
      final lastAction = _tableSource.undo.state.pop();

      // Undo the last action
      switch (lastAction.undoAction) {
        ...
        case UndoAction.reordered:
          _tableSource.rows.removeAt(lastAction.newIndex!);
          _tableSource.rows.insert(lastAction.oldIndex!, lastAction.oldState!);
          break;
        ...
      }
    });
    ...
  }
}

What an improvement! Comments and variable assignments are gone because it’s now understandable. A dependency is gone, because records are now a first-class language feature. A big thank you to the Dart team.

After writing this article I decided to double-check my link to the tuple package in pub.dev. The following notice is present:

By and large, Records serve the same use cases that package:tuple had been used for. New users coming to this package should likely look at using Dart Records instead. Existing uses of package:tuple will continue to work, however, we don’t intend to enhance the functionality of this package; we will continue to maintain this package from the POV of bug fixes.

Now, I understand some people will argue a class is a better structure for this, and they might be right. I feel however that a record works well in this instance, and happy to be enlightened with justified reasoning.

What do you think, are records a valid replacement for the tuple package here?

Other information

This post originally appears on my personal web site at https://dom.jocubeit.com/replacing-tuples-with-records.

I used my one free credit at STOCKIMG.AI to generate a horizontal poster using disco diffusion for the article poster image. My casual, yet very inadequate prompt was: “dart programming language code flying in background, records in the foreground”. The image above is the generated result. Nothing like what I was expecting, but kinda cool; so I thought I’d use it anyway.