Our current implementation has the following issue:
Schema are typed as FormSchema without specifying a generic type argument. example
This means the generic type defaults to FormData, which is just { [key: string]: any }, which causes most of our interactions with the form/library to be untyped (or, more specifically, to have the any type).
Instead, we should be declaring our schema similar to the following:
const schema: FormSchema<DefineStepRule> = { //...
And fixing all type errors that result from that.
There also seems to be an issue with the library itself, where providing a type parameter to FormSchema does not narrow the index signature of FormSchema, and so dealing with specific keys in the schema may still be untyped. My naive solution would start with this change:
-export interface FormSchema<T extends FormData = FormData> {
- [key: string]: FormSchemaEntry<T>;
-}
+export type FormSchema<T extends FormData = FormData> = {
+ [K in keyof T]: FormSchemaEntry<T[K]>;
+};
Pinging @elastic/siem (Team:SIEM)
Pinging @sebelga in case they have thoughts.
Thanks for raising the issue in the lib @rylnd! I created a separate issue to fix the FormSchema interface in the lib https://github.com/elastic/kibana/issues/60602
As mentioned above https://github.com/elastic/kibana/issues/60602 addressed the specific issue pointed out here. We still had a few ugly casts in our forms, but those were also addressed in https://github.com/elastic/kibana/pull/80842. IMO we're in a great position for now so I'm happy to close this. Thanks for all your help @sebelga !
Thanks for your patience @rylnd ! 馃槉
Most helpful comment
As mentioned above https://github.com/elastic/kibana/issues/60602 addressed the specific issue pointed out here. We still had a few ugly casts in our forms, but those were also addressed in https://github.com/elastic/kibana/pull/80842. IMO we're in a great position for now so I'm happy to close this. Thanks for all your help @sebelga !