RFC: field name translations

[idlehands]

Been thinking of ways that assert_values_for doesn't quite reduce effort and one of the more common places is when the two map-likes (map, struct, ecto schema) have different names for the fields, but the data is the same. An example might be when a database struct, Thing, has an id field, but a system event might call it something like thing_id.

As with the list assertions, I think the biggest challenge is the api/dsl to make it clear to someone unfamiliar with the library what is going on.

The fields list will need to be the source for the starting key. But then, is it assumed that the fields passed to fields are always a match to the fields on expected? If so, I think we could possibly get away with a less verbose, more implicit dsl, but I'm not sure that that is always the case. If not, we should be more explicit.

Here is a sketch of what it could look like. I would love feedback or ideas that aren't presented here at all.

      assert_values_for(
        expected: quote_request,
        actual: quote,
        fields: fields_for(OmniWeb.Schema.QuoteRequest),
        field_name_translations: [
          # explicit
          origin_postal_code: [actual: :origin_zip],
          destination_postal_code: [expected: :destination_zip, actual: :destination_zipcode],
          # implicit
          pieces: :freight_pieces, # assumes field is from expected and that this is on actual?
          weight: :freight_weight
        ],
        skip_fields: [
          :selected_common_pickup_accessorials
        ]
      )

[idlehands]

I have requested @GeoffreyPS also weigh in.

[lmarlow]

I like the implicit style, it feels more ergonomic.

[GeoffreyPS]

I welcome this feature. I also like the implicit style as the other more explicit style is very verbose as proposed (and I'm not sure how to reduce that).

[GeoffreyPS]

I'm trying to think of edge cases but I'm not sure if they are able to be encountered or real problems:

• Name collisions I don't think this is an issue since the mapping is provided

• It's possible to have multiple instances of the same entry in keyword lists Determining a last-one-wins or first-one-wins default should be sufficient, but maybe that should generate a warning.

• How this interacts with #39 I think one would have to assume that the list of key-value structures/map-likes would be the same in nature (e.g., a list of exclusively users or exclusively addresses) and not a list of multiple kinds of entities.