Skip to content

Conversation

@btrautmann
Copy link
Contributor

@btrautmann btrautmann commented Dec 22, 2025

📰 Summary of changes

What is the new functionality added in this PR?

This PR does the following (and includes ⚠️ Breaking changes ⚠️ ):

  • Updates dependencies, including the minimum required dart version
  • Drops the freezed and freezed_annotation dependencies which were previously used only to give us sealed-like classes. Since sealed class became a thing after this library was designed, we can drop that and used sealed directly. Note that the public API/constructors of these types (NetworkRequestBody and SturdyHttpEvent) has changed and will require adjustments (which should be doable via Find All + Replace).
  • Changes the conditions under which DecodingErrors are emitted. See the comment below.

🧪 Testing done

Unit test coverage feels sufficient here.

@btrautmann btrautmann requested review from a team as code owners December 22, 2025 21:03
samandmoore
samandmoore previously approved these changes Dec 22, 2025
Copy link
Member

@samandmoore samandmoore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

domainlgtm

just a few questions about stuff that we might not need anymore as well

@samandmoore
Copy link
Member

do we need to update the readme too? any examples?

onResponse: onResponse,
);
} on Exception catch (e) {
if (e is CheckedFromJsonException) {
Copy link
Contributor Author

@btrautmann btrautmann Dec 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: This is a behavior change. Previously, we'd only emit a DecodingError event if the Exception was a CheckedFromJsonException. That felt a bit smelly to me (it relies on the consumer's decoding implementation. I.e. if they used dart_mappable, a MapperException is thrown instead, and this check wouldn't ever emit). Now, we emit this event on every Exception thrown during deserialization. This encourages two things:

  • Keeping onResponse logic focused on just deserialization to minimize the chance of an Exception being thrown that's not related to deserialization
  • Allowing consumers themselves to decide if they "react" to a DecodingError (they can check if the passed Exception was indeed a variant they care about).

Copy link
Member

@samandmoore samandmoore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

domainlgtm

the exception event emitting behavior change makes sense to me too.

nice clean up!

@btrautmann
Copy link
Contributor Author

/no-platform

@btrautmann btrautmann merged commit 86a0c90 into main Dec 23, 2025
5 checks passed
@btrautmann btrautmann deleted the bt/chore/upgrades branch December 23, 2025 15:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants