Introduce static 'to map' functions

[noordawod]

No description provided.

[codecov]

Codecov Report

Merging #178 into develop will increase coverage by 0.01%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop     #178      +/-   ##
===========================================
+ Coverage    77.76%   77.78%   +0.01%     
===========================================
  Files           49       49              
  Lines         1381     1382       +1     
===========================================
+ Hits          1074     1075       +1     
  Misses         307      307

Impacted Files	Coverage Δ
floor_generator/lib/writer/dao_writer.dart	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a6473d1...c80bb9f. Read the comment docs.

[vitusortner]

Thanks for your contribution! What's your specific use case for private static mapper functions?

[noordawod]

It wouldn't be private if this is part of a library, which then I can reuse to expose get toMap functionality. So rather than writing it myself for every entity, I'd use this function. This works nicely because build_runner adds the relevant part of lib_name; to the generated *.g.dart file which is brilliant indeed.

get toMap can be used, among other things, to serialize the entity for use in a rest api.

By the way, I'm making use of this wonderful code a lot and if you need some assistance, I could help out. I've been working with Flutter for almost 2 years and engaged in many other open source Flutter plugins and libraries, feel free to contact me privately if you want a helping hand.

[noordawod]

What do you say about the pr, @vitusortner? This shouldn't affect the code really but it's very useful for my usecase, and basically when you architecture Floor as a library.

[noordawod]

Merged and all good.

[noordawod]

@vitusortner hope you'd be willing to merge this also, it's helping me when including Floor as a library.

[vitusortner]

Would you be so kind and show me a complete code example on how you would use this?

[noordawod]

It's internal code so hang on while I prepare something up...

[noordawod]

database.dart:

library my_dao;

part 'database.g.dart';

part 'entity/user.dart';

@Database(version: 1, entities: [UserEntity])
abstract class AppDatabase extends FloorDatabase {

  // Implementation hidden.

}

/// Entities extend this class.
abstract class BaseEntity {
  const BaseEntity);

  // Additional abstract requirements on entities go here.

  Map<String, dynamic> get toMap;
}

entity/user.dart:

part of my_dao;

/// Entity extends the BaseEntity
@Entity(tableName: 'users')
class UserEntity extends BaseEntity {

  /// First use.
  UserEntity.fromMap(<String, dynamic> map) => _$UserDao._userMapper(map);

  // Properties hidden.

  // Other implementations hidden.

  /// Second use.
  @override
  Map<String, dynamic> get toMap {
    final map = <String, dynamic>{};
    _$UserDao._userMapper(map);
    return map;
  }
}

[noordawod]

@vitusortner example above. 2 places where the function can be reused.

[noordawod]

Both used when communicating with a JSON-based RESTful API.

Learning from our previous merge experience, I would say that you'll probably introduce another mechanism to achieve this so I'm ready to adjust :)

[vitusortner]

I see the value in reusing the mapping functionality of the library, but I'm unsure if the suggested implementation is the best what we can get. Nevertheless, as it's such a small change, let's still merge it.