-
-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional generics #408
Additional generics #408
Conversation
The workflows are failing, and that's to be expected. I was also experimenting with changing the export interface ValueEditorProps<F extends Field = Field> extends SelectorOrEditorProps {
field: F['name'];
operator: NonNullable<F['operators']>[number] extends NameLabelPair
? NonNullable<F['operators']>[number]['name']
: NonNullable<F['operators']>[number] extends OptionGroup
? NonNullable<F['operators']>[number]['options'][number]['name']
: string;
value?: any;
valueSource: ValueSource;
fieldData: F;
type?: ValueEditorType;
inputType?: string | null;
values?: any[];
listsAsArrays?: boolean;
} So that if the props aren't using a custom type the operator should default to |
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit b5f8fa6:
|
Codecov Report
@@ Coverage Diff @@
## main #408 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 100 100
Lines 3089 3087 -2
Branches 1480 1480
=========================================
- Hits 3089 3087 -2
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
I think the workflows weren't actually failing (and they shouldn't since you've only modified types and not execution), they just weren't running because it's a draft PR. Anyway don't worry about those for now. I don't think we need to be so sophisticated with the type for the export interface ValueEditorProps<
F extends Field = Field,
O extends string = string,
V = any,
Vals = any> extends SelectorOrEditorProps {
field: F['name'];
operator: O;
value?: V;
valueSource: ValueSource;
fieldData: F;
type?: ValueEditorType;
inputType?: string | null;
values?: Vals[];
listsAsArrays?: boolean;
} Inference from the const operators = [{ name: '=', label: '=' }, { name: '!=', label: '!=' }] as const;
type Op = (typeof operators)[number]['name'];
const CustomValueEditor = (props: ValueEditorProps<Field, Op>) => {
/* ... */
}; |
I actually like that a lot better, it's easier to understand than my mess and is more aligned with the generics in the I'll update this PR with changes similar to that if not those exactly in the next few days |
Here's an idea for generics on the -export interface NameLabelPair {
- name: string;
+export interface NameLabelPair<N extends string = string> {
+ name: N;
label: string;
[x: string]: any;
}
export type OptionGroup<Opt extends NameLabelPair = NameLabelPair> = {
label: string;
options: Opt[];
};
-export interface Field extends NameLabelPair {
+export interface Field<
+ N extends string = string,
+ OpName extends string = string,
+ OpObject extends NameLabelPair = NameLabelPair<OpName>
+> extends NameLabelPair<N> {
id?: string;
- operators?: NameLabelPair[] | OptionGroup[];
+ operators?: OpObject[] | OptionGroup<OpObject>[];
valueEditorType?: ValueEditorType | ((operator: string) => ValueEditorType);
valueSources?: ValueSources | ((operator: string) => ValueSources);
inputType?: string | null; |
That will certainly work better than my current existing flow for the way I use the I should be able to make these changes tonight and commit them, apologies for the delay in responding . |
This looks good so far. The one thing I'm wondering about is the order of generics on I'm thinking it might be better to have them in this order, with export interface Field<
FieldName extends string = string,
OperatorName extends string = string,
+ ValueName extends string = string,
OperatorObj extends NameLabelPair = NameLabelPair<OperatorName>,
- ValueName extends string = string,
ValueObj extends NameLabelPair = NameLabelPair<ValueName>
> extends NameLabelPair<FieldName> {
// ...
} This way the user could define the types for the Implementation would be like this: type MyFieldNames = 'f1' | 'f2';
type MyOperators = '=' | '!=';
type MyValues = 'v1' | 'v2';
type MyField = Field<MyFieldNames, MyOperators, MyValues>; The way it is now would require the user to do this: type MyField = Field<MyFieldNames, MyOperators, NameLabelPair<MyOperators>, MyValues>;
// ^ unnecessary; equivalent to default |
That's a good catch, the positional generic arguments make more sense in that pattern. Pushing that update now |
@all-contributors please add @Austin-Stowe for code. |
I've put up a pull request to add @Austin-Stowe! 🎉 |
First discussed in #406.
Purpose
To add generic support for custom
Field
types used for access when creating custom value editors.Code Changes
packages/ts/src/props.ts
ValueEditorProps
ValueEditorProps extends SelectorOrEditorProps
toValueEditorProps<F extends Field = Field> extends SelectorOrEditorProps
F
type to fields in interface to inherit any custom fields added to theField
type by way of the[x: string]: any
available inNameLabelPair