Make ValueEditorProps
use a generic Field type
#406
Replies: 2 comments 4 replies
-
Hi @Austin-Stowe! Thanks for all the detail here, it's really helpful. I'm especially glad you find I think you have the beginning of a good idea, but I'd like to flesh it out a little. We should probably add generics for more than just the field-related props in One note about your Why don't you go ahead and submit the PR and we can work on it from there. (Undo the modifications to |
Beta Was this translation helpful? Give feedback.
-
I was going through old issues and discussions looking for something else, and I came across this one and realized it was the initial driving factor for the huge TypeScript improvements in RQB v7. Thanks for kicking off the process, @Austin-Stowe! |
Beta Was this translation helpful? Give feedback.
-
General Idea
I use this component at work to support building a react hosted UI that allows users to manage Drools rules and have built my own translation layer from a combination of the provided
formatQuery
andtransformQuery
options that serves all my needs.What I have had to customize, and thankfully haven't had much of an issue with, is customizing some of the types to have stronger typed custom field names and operators, which are built from a combination of TypeScript enums with string values and template string literal types. This works great since in we need to enforce that field names match a set of known values, and I've managed this with a custom type that looks like
And by using this
CustomField
type we can enforce that field names match an expected format using the mapped type. I do a similar thing for the operators, since using custom operators makes translating to the Drools language format significantly easier.Since the
Field
type provided by the library extendsNameLabelPair
and as such allows for a field of type[x: string]: any
, this means we can add new fields to ourCustomField
type that we can leverage later on.The first use case I can think of for this is when customizing the ValueEditor, where we can build custom editing experiences for the users based on potentially a combination of the field name and perhaps a
dataType
field similar to the example in the documentation.Proposed solution
Change the
ValueEditorProps
interface toWhich yields the following benefits:
Field
type similar to what we are using would be able to pass the template strings literals directly into the ValueEditorPropsfieldData
field would then have access to the same valuesIn the [example demonstrating how to use custom components](similar to the example in the documentation, this would give IntelliSense for the developer if the had a type that looked like
Pretty much all the other types from this library support generics well enough for me to pass around the customized types I've built, this is the last use case I can think of currently. I've already forked the repo and can open a PR with the changes if you'd like, unless there's another edge case I'm missing that this would break.
Beta Was this translation helpful? Give feedback.
All reactions