[RFC] Deprecating custom MapperContainers

[schultek]

I'm looking into deprecating the feature to create custom MapperContainers and trying to understand how that would affect current users of the package.

What would be deprecated and removed in a future version.

Creating custom instances of MapperContainers and container linking.
The following would not be possible anymore:

void main() {
  var container1 = MapperContainer();
  var container2 = MapperContainer();
  
  container1.use(MyClassMapper());
  container2.link(container1);
  container2.fromJson<MyClass>("...");
}

What would not be deprecated or removed.

Using the global instance of MapperContainer.globals or a similar static construct will continue to work.
The following would still be supported (but maybe have a different syntax):

void main() {
  MyClassMapper.ensureInitialized();
  MapperContainer.globals.fromJson<MyClass>("...");

  MapperContainer.globals.use(MyCustomMapper());
  MapperContainer.globals.fromJson<MyCustomType>("...");
}

Why the change?

Removing MapperContainers could potentially greatly improve performance of this package while also reducing complexity of the implementation.

Who is affected?

Its unclear how many users (if any) actually use this feature but I recon quite few. The main feature custom containers are used for is scoping mappers to only a part of your application, or having different mappers for the same type.

Its debatable if these cases even are desirable for serialization, but If needed could potentially also be implemented without custom mappers through manual setup.

---

@nblum37 @point-source @caseycrogers Tagging you since you have been involved in this package before. Kindly let me know if or how you use this or if you have any comments.

[point-source]

Thanks for considering me! I believe that at this time, all my projects use the global container. I can't recall having had to scope any mappers so far.

A bigger pain point for me at the moment is what happens when one package depends on another and both depend on dart_mappable. Specifically as it relates to version mismatches and mapper discovery. Can go into more detail on this later.

[caseycrogers]

Thanks for the heads up!

I do not use MapperContainer at all so this is fine with me.

[Zekfad]

I think that there's needed a better mechanism to make it easier to work with modules that uses dart_mappable internally.
As of now, Mapper Container is hardly useful because it's pain to setup manually and manage all mappers.

I think that idea of mapper Container on itself is a good, but it needs a better consideration (to make implementation less constrained and allow for performance shortcuts) and to make it easier to share or to exclude mappers for dependency chains

I think that mapper containers just need to be remade into a better protocol, here are some bullets that really needed in my opinion:

• to make a convention for sharing/excluding mappers from package public interface
• such convention should be versioned and be consistent in major releases, so public packages will use more broad version constraint e.g. ">=2" and do not publish generated code, instead code is always generated by end user for all dependencies
• use performance shortcuts when they available: if convention will agree that users generate code, we can most of a time skip global lookups and use needed mappers directly, taking into consideration what mappers are available for given scope
• user level control over mappers discovery flow, e.g. user can isolate specific packages from their app state, that can be done as config or annotation options (again we can fully determine and generate all the needed stuff without runtime penalties)

While it may sounds like a huge effort, I think in a long term it would make package easy and safe to use in supply chains: package maintainers will receive flexible tool that would support extensible data without additional efforts (generics would be able to utilize other packages mappers) and users receive a neat API with multiple packages magically works with themselves with no additional efforts, at the same time if needed stuff can be configured for a more tight requirements.

Hope this idea/s will help you