It would be nice to be able to extract a more exact field type when using the “number of records” validation rule for modular content fields (using graphql codegen).
Example of an optional “Link” block:
This means the CDA can return data like:
Codegen will generate a type:
When accessing the modular content field with
link we still get
LinkRecord type while the type can be
undefined as well. We can of course mitigate this issue by using
noUncheckedIndexedAccess tsconfig compiler rule to enforce checking for undefined values (this has other implications, more on that later).
The compiler rule does not however help our developers to differentiate between optional modular content fields just by looking at the generated types / schema. We can only see the validation rules from within Dato.
It would make sense if codegen could generate a type like this when a modular content field can be left without any blocks i.e. an optional field:
Related note about using “noUncheckedIndexedAccess”
noUncheckedIndexedAccess is tricky because it can also surface issues with third party packages that come with the
.ts source. Skipping type checking can’t be avoided for code in “node_modules” at this point.
For example, the dato rest client includes the source code in the NPM package which fails type checking with “noUncheckedIndexedAccess” enabled. This prevents us from publishing code changes with this compiler setting as it doesn’t pass through our CI.
Maybe consider removing the unnecessary(?)
.ts source from your NPM packages?