Modddels
HomeGithubPub.dev
v0.2
v0.2
  • Motivation
  • Setup
  • Generalities
    • Modddels Overview
    • Validations & Validation steps
    • Structure of a Modddel
    • Member parameters & Dependency parameters
    • Usage
      • Data equality & toString
      • Pattern matching
      • Reading the fields
      • Reading the failures
      • CopyWith
  • ValueObjects
    • ValueObjects Overview
    • Creating a ValueObject
  • Entities
    • Entities Overview
    • ContentValidation & ContentFailure
    • ValidationSteps in Entities
    • SimpleEntity
      • Creating a SimpleEntity
      • Special Cases
    • IterableEntity & Iterable2Entity
      • IterableEntity / Iterable2Entity kinds
      • The Type Template
      • Creating an IterableEntity / Iterable2Entity
      • InvalidMembers Description
      • Special Cases
      • Creating your own IterableEntity / Iterable2Entity kind
  • Advanced Notions
    • The NullFailure Annotation
    • Using multiple parameters annotations
    • Class Hierarchy of ValueObjects
    • Class Hierarchy of Entities
    • Models that are always valid / invalid
  • Union of Modddels
    • Union of Modddels Overview
    • Basic Usage
    • Case-modddels pattern matching
    • Default Factory Constructor
    • Shared Properties
    • The Validate Methods
    • CopyWith
  • Unit-Testing Of Modddels
    • Unit-Testing Overview
    • Available Tests
    • Customizing Tests
  • Additional Information
    • Using type aliases
    • Re-running the generator
    • All Available Modddels
    • VsCode Snippets
Powered by GitBook
On this page
  1. Union of Modddels

Basic Usage

PreviousUnion of Modddels OverviewNextCase-modddels pattern matching

Let's continue with our Weather example .

The super-sealed classes (Weather, ValidWeather, InvalidWeather and InvalidWeatherValue) replicate the same functionality of modddels :

// NB : In these examples, the types of the variables/callback parameters is specified 
// only for the sake of showing their types to you. You don't need to do so.

final Weather weather = Weather.rainy(
  temperature: 12,
  rainIntensity: 0.9,
);

You can use isValid, toEither and toBroadEither :

bool isValid = weather.isValid;
Either<InvalidWeather, ValidWeather> either = weather.toEither;
Either<List<Failure>, ValidWeather> broadEither = weather.toBroadEither;

All pattern matching methods we've seen so far can be used too : map, mapValidity, maybeMap, mapOrNull, maybeMapValidity, mapInvalid, whenInvalid, etc... :

final message1 = weather.map(
  valid: (ValidWeather validWeather) => 'This weather is habitable',
  invalidValue: (InvalidWeatherValue invalidWeatherValue) =>
      invalidWeatherValue.habitableFailure.when(
    tooHot: () => "Humans would die of heat",
    tooCold: () => "Humans would freeze to death",
  ),
);

final message2 = weather.mapValidity(
  valid: (ValidWeather validWeather) => 'Valid weather',
  invalid: (InvalidWeather invalidWeather) => 'Invalid weather',
);

You can also access the failure(s) :

weather.mapOrNull(
  invalidValue: (InvalidWeatherValue invalidWeatherValue) {
    WeatherHabitableFailure failure = invalidWeatherValue.habitableFailure;
  },
);

(you can find it here)