openshift
CONSOLE-4675: Enable strictNullChecks: true for olm and olm-v1
Key Guidelines
When addressing TypeScript errors related to strictNullChecks, keep the following guiding principles in mind:
Type Matching: Ensure that parent and child component props and their corresponding types are always consistent and correctly matched.
Avoid Ambiguous Types: Do not use overly broad or ambiguous types such as any, and do not use type assertions using the keyword as. NEVER assert objects, variables, or parameters using as any. Using these types defeats the type-checking purpose of TypeScript and can lead to runtime errors that are difficult to debug.
Enforce Strict Typing: Always use the correct and most specific type for a variable or prop. For example, if a prop is a string, its type should be string, not undefined.
Favor Optional Chaining: Prefer using optional chaining (?.) for accessing nested properties. This practice improves code readability and prevents errors when a property might be null or undefined.
Use precise Kubernetes types: When dealing with Kubernetes resources, use the most precise types available to ensure accurate configuration and interaction with the API. We're frequently using generic types like K8sResourceCommon, which define metadata.name and metadata.namespace as optional. However, in many of our use cases, we know these properties exist. name is almost always required, and namespace is mandatory for namespaced resources. Instead of littering the code with optional chaining (?.) to access them, let's use or create more specific types that accurately reflect the resource's shape. This strengthens our type safety and removes unnecessary null checks.
Fix the Root Cause, Not Just the Symptom: Avoid using union types (| null), type casting (as), and any to resolve compiler errors. While effective, these can sometimes act as a band-aid, masking deeper issues in our type definitions. Let's treat a type error as a signal to investigate the underlying data model. Instead of forcing a type to fit, let's ask why the type is incorrect and aim to fix it at the source.
Initialize with Fallbacks, Don't Handle Nulls Repeatedly: Let's define sane default values at initialization instead of applying nullish coalescing (??) or logical OR (||) fallbacks every time a variable is used. This makes the variable's state predictable and reduces redundant code. This is especially helpful for deeply nested properties—extract them into a clearly named variable with a default.
Favor Optional Chaining for Readability: When destructuring potentially nullish objects, providing a fallback object (e.g., (foo ?? {})) can obscure the code's intent. A more readable and explicit approach is to use the JavaScript optional chaining operator (?.) for each property. This clearly communicates that the source object might be null and provides safe defaults for each value independently.
Use OpenShift console-specific idioms and types: In new code, OpenShift console uses specific types such as React.FCC instead of React.FC to type components, to fix certain issues with legacy dependencies. Prefer using React.FCC when fixing types issues related to components returning null.
