includeTypeId as MappableClass parameter / Fine-Grained Control Over __type Attribute in Serialization (Feature Request

[otmi100]

First of all, thank you for your amazing work on this package!
It’s clear that a lot of thought and effort has gone into it, and it truly makes working with Dart cleaner and more enjoyable. I appreciate the superb ideas and functionality it offers.

That said, I have a feature request related to serialization:

Context

I’m working with an OData backend that does not allow any extra attributes in the serialized output. Specifically, I’m encountering an issue with the __type attribute being added during serialization.

Here’s the setup:

• I have a Package class that extends an Article class.
• When a Package instance is serialized as part of another class (e.g., Component), the __type attribute is automatically added.

---

Current Workarounds

I’ve explored the following options, but they don’t fully address my needs:

1. Using ComponentMapper.ensureInitialized().encodeMap(self, EncodingOptions(includeTypeId: false))

   • This disables the __type attribute but applies it to the entire object tree.
   • I only want to omit __type for the Package class, not for every class in the tree.

2. Using an afterEncode Hook

   • I attempted to remove the __type attribute with an afterEncode hook.
   • Unfortunately, it seems that the __type attribute is added after the hook is executed.

Also calling ComponentMapper.ensureInitialized().encodeMap(self, EncodingOptions(includeTypeId: false)) is more cumbersome that the toMap() of the Class Mixin.

---

Proposed Solution

It would be great to have fine-grained control over the inclusion of the __type attribute. Specifically:

• Allow disabling __type on a per-class basis rather than for the entire object tree. Alternatively it could be a option of a MappableField annotation of the outer class (e.g. Component)?
• Ensure that hooks (e.g., afterEncode) can modify or remove the __type attribute if needed.

---

Why This Matters

This feature would make the package more flexible and compatible with strict backends like oData, where extra attributes are not allowed. It would also improve developer experience by enabling more targeted control over serialization behavior.

---

Thank you for considering this request! Let me know if you need further clarification or examples to better understand the use case.

[otmi100]

is related to #250