Allow specifying type converters

[DevNico]

Allow specifying type converters

[tenhobi]

Cc @DevNico @wstrange @jacktattersall1 v2.0.0 is now in release :)

[DevNico]

I don't think it makes sense to limit this to primitives since the logic doesn't have any requirement for it. It's just a general type mapping thingy.

[petrnymsa]

I really like this idea and I am definitely for some form of "type converters" thing.

[DevNico]

I split up this issue into two since I think both are relevant separately, see #61. I updated this issues title and description to better reflect the feature request.

[tenhobi]

Hi @DevNico @wstrange, we would like to focus on this task now. 🙌

Before that, we would like to share our design. If you have some comment on it, please do it now.

Basically mapping now works by naming, which will be left as is. Then we add converters, which will check type of source and target and make decision what to do. Also, we will try to match converters before mappings.

• match source and target
• when the type match, leave it
• when the type does not match, check converters (by order by default, and possibly prefer specific if possible)
  • we will allow you tu map from/to "any" value, aka from any to Value<String>, from String to Value<any> or from any to Value<any> (🤞) either using some contravariant "hacks", using Object to mark these "any", or create an Any constant class.

@AutoMappr(
 [
    MapType<A,B>(
       // ...
       converters: [
         // exact match
         Converter<TimeStamp, DateTime>((value) => DateTIme()...),
         Converter<int, Value<int>>((value) => ),
​
         // replace ints with Value<whatever you want>
         Converter<int, Value<ANY>>((value) => ...),
         // replace ints with whatever you want
         Converter<int, ANY>((value) => ...),
       ],
    ),
    MapType<User,UserDto>()
 ],
 converters: [
   // ...
 ],
)

[tenhobi]

@tomwyr hi, could you make a minimal reproducible example?

It should work no matter what it is, but we still recommend them only for type concerting some leaf data (eg String to datetime etc).

I will take a look on that :)

[tenhobi]

Thanks, I will investigate the issue, probably tomorrow. This seems like something that should work. 👍

[petrnymsa]

@tomwyr Hi, thanks for report, could you please create separate issue, so we can easily track it? Thank you

[tomwyr]

Awesome. Thanks for solving it so quickly!

[tenhobi]

Should this work generally, or only for converting to primitives like String, int, ...? 🤔

[tenhobi]

I see, I will just link it with #11 as it is a specialized case of this just for primitives. I think it might be useful for sure and we can give it a thought. Wanna chat about it sometime on our Discord? (link in readme)

[tenhobi]

So basically, fields (current positional parameter) will match stuff based on fields names, and this feature would solve for these matched fields from source to target a conversion when fields' source and type types mismatch (?) from field type A to field type B, when custom is not used, right? And these type conversions would be set for MapType so they can be reused, and also maybe on AutoMappr to be "globally" used? (supposedly only in the scope of current Mappr, not imported ones, etc.)

Kinda like the idea; we can solve issues like a problem in the #29 discussion about converting int to Value<int> with Drift etc., in one place. 👍

Can someone think of some side effects this can have?

[tenhobi]

Just to mention the idea again: it would be cool if it works for fields, MapType (all fields) and AutoMappr (everything in this mappr "module").

So try your POV. We can discuss the specs if you need.

[wstrange]

Chiming in with my use case:

Map a protobuf Timestamp object to a DateTime for all DateTime fields of a target object (without needing to specify the conversion for each field individually).

[tenhobi]

@wstrange, thanks for your addition to this topic. We also did some discussions in that draft PR and Discord, and right now, I am team custom on MapType that will cover the most reasonable cases. But we will see; let's consider it more since it can be a big step. ☺️

[wstrange]

That looks good to me. I assume the outer converters is a global catch-all? I think this would cover all the corner cases that I ran into.

[tenhobi]

Yes, that's global in the mappr scope. We still have to make some proves of concepts, but we will keep this thread updated 👍

[tenhobi]

Will be available in v2, now available using version 2.0.0-beta2

[tomwyr]

@tenhobi
Should global converters also work for nested objects? I'm having troubles generating code with a custom converter, where generator says the following, even though appropriate converter is registered in mappr (as a global one):

Trying to map nested object from "_i11.ScheduleDateRule date -> _i10.ScheduleDateRuleDto date" but no mapping is configured.

[tomwyr]

The error doesn't occur, if I set the converters explicitly on the type mapper that needs them, although, that way, if the code grows, it needs to be done multiple times + apparently I lose the ability to use reverse.

[tenhobi]

Interesting, it should not matter whether you put type converters globally or on specific mapper, since we merge those lists.

Please provide a minimal reproducible example so I can see what you doing and what's suppose to be wrong. :)

[tomwyr]

Global converters seem to work incorrectly when combined with the reverse flag. Here's a simple example where I was able to reproduce that behavior using a simple types structure:

import 'package:auto_mappr_annotation/auto_mappr_annotation.dart';

import 'mappr.auto_mappr.dart';

@AutoMappr(
  [
    MapType<PostDto, Post>(reverse: true),
  ],
  converters: [
    userDtoConverter,
    userConverter,
  ],
)
class Mappr extends $Mappr {}

class Post {
  final User user;
  Post({required this.user});
}

class PostDto {
  final UserDto user;
  PostDto({required this.user});
}

class User {
  final String id;
  User({required this.id});
}

class UserDto {
  final String id;
  UserDto({required this.id});
}

const userDtoConverter = TypeConverter(_userDtoToUser);
const userConverter = TypeConverter(_userToUserDto);
UserDto _userToUserDto(User source) => UserDto(id: source.id);
User _userDtoToUser(UserDto source) => User(id: source.id);

Now, if mappers are expressed as two separate entries, the error is gone:

@AutoMappr(
  [
    MapType<PostDto, Post>(),
    MapType<Post, PostDto>(),
  ],
  converters: [
    userDtoConverter,
    userConverter,
  ],
)
class Mappr extends $Mappr {}

[tenhobi]

@tomwyr fixed in #127, we forgot to pass type converters to reverse :D