Record/Field Factories

[harrysolovay]

Why is it that we define the shape of a record codec as follows?

const c = s.record(
  s.field("name", s.str),
  s.field("nickName", s.str),
);

At first glance, it seems strange that we must call s.field... couldn't we bypass this bloat?

Why wouldn't the following work?

const c = s.record({
  name: s.str,
  nickName: s.str,
});

Unfortunately, the field order needs to be known for encoding. There's no way for us to reflect on this info [EDIT] well using a JS record. We could certainly allow fields to be defined via tuples:

const c = s.record(
  ["name", s.str],
  ["nickName", s.str],
  // ...
);

The issue with this is that string literals "name" and "nickName" are widened to string.

type C = s.Native<typeof c>;

assertTypesEqual<C, {
  name: string;
  nickName: string;
}>();

// ^ this would produce an error, as the actual signature is `Record<string, string>`

We must assert as const in order to get the literal typings of keys, which flow into the signature of c.

const c = s.record(
  ["name", s.str] as const,
  ["nickName", s.str] as const,
  // ...
);

It's very easy to forget to as const-ify––better to safeguard via the extra factory field.

Additionally, the Field type / field factory is used elsewhere (tagged unions).

[josepot]

Unfortunately, the field order needs to be known for encoding. There's no way for us to reflect on this info using a JS record

Why not?

JS does have a guaranteed property order. This is something that was standardized on ES2015 and even before then it was a de facto standard across JS engines. That's why @unstoppablejs/scale admits JS Objects on its Struct higher order codec.

[harrysolovay]

This is a great comment & makes sense: seems ES2020 really solidified order access for object literals... but there are other ways in which devs may initialize codecs. Just to be safe, I'd prefer explicit indication of order... what do others think?

[harrysolovay]

This playground showcases a shortcoming of implicit ordering: the field order of objects of multiple key types does not seem to be preserved. It seems they are grouped. We want to enable decoding to / encoding from any PropertyKey. Thoughts @josepot?

[harrysolovay]

Another issue: many devs configure key sorting via formatters (for instance). They would need to disable such formatting.

[harrysolovay]

Addressed in PR #17 – locking conversation