lovasoa / json_in_type Goto Github PK

Currently, in order to use json_object! macro you also have to import inlined_json_object! macro. This is codified as the recommended way to just use json_in_type::*; and import everything exported by json_object.

It's not strictly necessary as json_object! macro could be restructured include inlined_json_object!. The typical trick is to reserve some special branch:

macro_rules! json_object {
    (inlined @ key : $key:ident, value : $value:expr, next : $next:expr) => {
        // inline inlined_json_object! implementation here
    };
}

This would make it unnecessary to use blanket imports (which pollutes namespace a bit), or import some extra implementation detail magic macros as well.

Though, note that inlined_json_object! has been exported and removing it might be a breaking change for those who have explicitly imported it. Optimizing json_object! might also be a “breaking change” of a different kind (since inlined_json_object! would no longer be used, all its imports would cause “unused import” warnings).

How would one map an iterator of different json_object! (i.e. from a match expression) into a single list – for example, a collection of GeoJSON features (each of which can be type "Point", "LineString" etc.)

Many libraries and frameworks use the Serialize trait from serde. It has become a de-facto standard.

Serializing through this trait would be a little slower because of the limitations it imposes, so it shouldn't be the default. However, the main performance gain of this library comes from the complex types it generates, and these types could perfectly implement the Serialize trait.

I've quite enjoyed json_in_type being faster at JSON serialization than serde. Thanks a lot for creating this crate!

Though, there were some itches that required scratching. One of them is optional field support in json_object! macro. It's possible to compute field keys with the following syntax:

json_object! {
    [computed_key]: value,
}

but it's currently not possible to serialize optional fields nicely. Suppose you have

{
    "foo": 123,
    "bar": 456,
    "baz": 789
}

where bar and baz can be optional and not included into the object. With json_object! the only option you have right now is to encode all four object variants explicitly:

• foo
• foo, baz
• foo, bar
• foo, bar, baz

I have a private fork of json_in_type which adds the following features to json_object! macro that make the above possible.

1. Computed optional keys:

    json_object! {
        (maybe_key): value,
    }

   where maybe_key is an Option with key name. If the key is None, it's skipped. Otherwise the Some value is used. This thing was useful to produce minified JSON with optional fields.

2. Skip fields by Option values:

    json_object! {
        key?: maybe_value,
    }

   where maybe_value is an Option. If it's None, the field is skipped from JSON form. Otherwise it's included.

What do you think about this?

I realize that those approaches might not be the best for everyone. Consider this a start of the discussion about how it might look like.

I have an API which has fields written like so:

{
   "inventory-location": "uuid",
   "inventory-parts": ["uuid", "uuid"],
}

Although this does not work here, given that it assumes to take a ident for each field name.