hydro-sdk VS freezed

There is already a project trying to bring Typescript into Flutter, but its on early development: https://github.com/hydro-sdk/hydro-sdk This will also probably create many extra pains for developers since existing Dart packages would have to be wrapped.

It's probably vastly more trouble than it's worth, but you could technically write the package in Typescript and use Hydro SDK to compile it to Lua bytecode that can run on the Dart VM with Flutter bindings, then distribute that bytecode with a package that wraps the Hydro API.

As an open source author, I've been thinking about some general and domain specific optimizations https://github.com/hydro-sdk/hydro-sdk/issues/797 I'd love to chat if OP has time.

In terms of interoperability, the short answer is mostly-yes. Any Dart code can be made to interoperate with code written using Hydro. Taking an existing Dart package and making it useable from Hydro is automated. The tooling isn't quite ready for prime time (nor is the entire SDK) https://github.com/hydro-sdk/hydro-sdk/tree/master/lib/swid

Hydro-SDK has a small Dart-like language built into it to support binding generation (https://github.com/hydro-sdk/hydro-sdk/tree/master/lib/swid/frontend/swidi).

The analyzer API is enormous. I've had a lot of success using the analyzer API, but abstracting over it with my own ASTs that can be manipulated and transformed (https://github.com/hydro-sdk/hydro-sdk/tree/master/lib/swid) and using code builder (https://github.com/dart-lang/code_builder) to emit Dart code.

I've been having a lot of fun writing a compiler in Dart (in a pure functional style, with pattern matching and sum types!) over here https://github.com/hydro-sdk/hydro-sdk/tree/master/lib/swid

There is the `sealed` class modifier which allows for exhaustive matching on possible types: https://dart.dev/language/class-modifiers#sealed

There's also a package called freezed which offers similar utility (you might already be familiar with this seeing as you mentioned pattern matching): https://pub.dev/packages/freezed

I recall there being a reason unions aren't generally implemented, though I'm not sure where I read it. It was to do with union types being unnecessarily complex for the compiler and the code they tend to produce, at no real benefit to the programmer or the resulting program. Go's lack of unions is essentially based around the same reasoning.

Interesting. May I ask how this differs from something like Freezed https://pub.dev/packages/freezed and its from/ToJson features ? I haven't used it yet, but I'm just curious about the concept and use of these sort of packages.

The official site does show what you can use it for but to explain a bit more, it helps you work faster.

One rather minor suggestion: it took me a while to understand exactly what the benefits were, but the example shown on this page of the docs summarized it well. I would suggest showing an example like that at the top of the main Readme and first page of the site, before or right after the motivation section, similar to how Freezed immediately shows its value proposition.

Read more on what you can do with Freezed.

freezed on pub.dev

We use freezed for our models, and then use withConverter in the firestore SDK to easily translate between firestore and our models... however we run into issues with concurrent updates to documents.

Once the package has been created, we will install freezed for JSON serialization and value equality , as this library provides helpful tools for these tasks. We will use json_serializable for JSON serialization. To install freezed and freezed_annotation, open your terminal inside the models package and use the command:

Data class: freezed

I've recently been exploring a codebase which is heavily using Freezed with Bloc. The resulting code base is almost an entirely different language altogether, and comes with almost triple the files of a non-freezed codebase.