As a result - we cannot rely on a compile to ensure the object is complete (unlike objects that are created without external inputs). All we can do is "cast" it via unknown so that the typescript compiler believes it's the right type.
This means that currently at runtime values can be null.
I think there's possibly also a gap with how we load static & runtime defaults vs user config (it doesn't look like the "programatic value" concept is represented in user config)
https://github.com/strimzi/strimzi-ui/blob/4a5d063b0a894541eed60c2de716e17467db5007/server/serverConfig.ts#L57 - we have two config inputs - default config, and user overrides. Default config has runtime concepts (values that by default still require runtime info). User overrides can only ever be loaded at runtime.
As a result - we cannot rely on a compile to ensure the object is complete (unlike objects that are created without external inputs). All we can do is "cast" it via
unknown
so that the typescript compiler believes it's the right type.This means that currently at runtime values can be null.
I propose we try https://github.com/pelotom/runtypes (from https://blog.logrocket.com/using-typescript-to-stop-unexpected-data-from-breaking-your-app/) - the ability at runtime to assert external input conforms to a type.
I think there's possibly also a gap with how we load
static
&runtime
defaults vsuser
config (it doesn't look like the "programatic value" concept is represented in user config)