RDART-771 EJSON support

[nielsenko]

Support de-/serialization to EJSON

The interface is basically:

typedef EJsonValue = Object?;
EJsonValue toEJson(Object? value);
T fromEJson<T>(EJsonValue ejson);

with some convenience extensions, so you can do 1.toEJson(), and {'\$numberLong': 1}.to<int>(), etc.

It support generics types:

// this returns a List<int> not a List<dynamic>
List<int> ints = fromEJson([{'\$numberLong' : 12}, {'\$numberLong' : 02}]); 

and custom types:

class Simple {
  final int i;
  // Annotation mark this ctor as the one to use for decoding. 
  // It also implies that a set of similarly named gettes must exists for encoding
  @ejson   
  const Simple(this.i);
}

Fixes: #1254

[nielsenko]

I think it is in a state where I'm starting to feel I have a good sense of direction. I can de-/serialize fairly complex stuff including generics (Fx List<int> vs List<String> which is important for realm, but even complex stuff like Map<String, List<Map<String, Object>>> .. which is not important for realm just yet, but will be once all variants of collection in collections lands). It also handles the relaxed mode of EJSONv2, unlike .NET.

Tons of stuff is missing (BSON has some very special types), but all the ordinary stuff is there, and branch coverage is around 70%, so I feel confident the bases are covered.

What remains (in my head) is the actual build_runner tool that handles custom types. There is an example Person class and a hand-written person.g.dart that illustrates what I'm aiming for.

I don't think we need to support all BSON types from the get go, as long as we support realm types it should be okay, and I don't think we need to support serializing to the binary format (hence I call the package ejson, not bson).

Anyway, I guess it is a good time to spend a bit time with it to see if you feel confident in the direction I have taken.

[desistefanova]

It seems we are on the right way.
Perhaps, we will have to add a property annotation that will allow different property names in the schema on the server. Something like MapTo.

[nielsenko]

It seems we are on the right way. Perhaps, we will have to add a property annotation that will allow different property names in the schema on the server. Something like MapTo.

The idea I'm working on is that this will be handled without annotations like:

class PrivateMembers {
  final int _id;

  int get id => _id; // must match constructor parameter name

  @ejson
  PrivateMembers(int id) : _id = id; // instead of @MapTo
}

Anything more fancy will require the user to register a codec pair (encoder + decoder function) with a class annotation.

[coveralls]

Pull Request Test Coverage Report for Build 8174716768

Details

• 278 of 307 (90.55%) changed or added relevant lines in 15 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-3.2%) to 86.567%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
packages/ejson/lib/src/encoding.dart	93	95	97.89%
packages/ejson/lib/src/types.dart	11	15	73.33%
packages/ejson_generator/lib/src/generator.dart	28	33	84.85%
packages/ejson/lib/src/decoding.dart	114	132	86.36%

Totals
Change from base Build 8172267667:	-3.2%
Covered Lines:	5742
Relevant Lines:	6633

---

💛 - Coveralls