This is problematic because our TypeScript type definitions do not reflect the actual runtime value. This would lead into pitfalls such as:
function foo(fsv: FileStructureValidation) {
// 👇 Since `ignore_in_submission` equals `null` for nullish values and it will never
// equal to `undefined` in runtime, this condition never evaluates to true in runtime!
if (fsv.ignore_in_submission === undefined) {
// ...
}
}
Solution
Hence, we should convert all null to undefined when parsing the config YAML.
Note that in configToYaml(), it already converts all undefined fields to null because the YAML parser does not understand undefined.
Problem
Using
undefined
In TypeScript, we model nullable fields in the config YAML using
undefined
. For example:A huge benefit of using
?:
to mark a field as nullish is that we do not need to insert that key in an object. For instance:If we're to use
null
, it becomes very verbose:Pitfall
However, we specify nullish values in YAML with
null
instead ofundefined
. For example:Therefore, in the actual data returned by the GraphQL, nullish values equal
null
.This is problematic because our TypeScript type definitions do not reflect the actual runtime value. This would lead into pitfalls such as:
Solution
Hence, we should convert all
null
toundefined
when parsing the config YAML.Note that in
configToYaml()
, it already converts allundefined
fields tonull
because the YAML parser does not understandundefined
.