Skip to content
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

Use ZodTypes instead of type_constants.ts #673

Open
jkomoros opened this issue Nov 10, 2023 · 0 comments
Open

Use ZodTypes instead of type_constants.ts #673

jkomoros opened this issue Nov 10, 2023 · 0 comments

Comments

@jkomoros
Copy link
Owner

Currently a lot of enum types are created by having a pattern like this:

//type_contstants.ts
export const BEFORE_FILTER_NAME = 'before';
export const AFTER_FILTER_NAME = 'after';
export const BETWEEN_FILTER_NAME = 'between';

export const DATE_RANGE_TYPES = {
	[BEFORE_FILTER_NAME]: true,
	[AFTER_FILTER_NAME]: true,
	[BETWEEN_FILTER_NAME]: true,
};

//types.ts
export type DateRange = keyof typeof DATE_RANGE_TYPES

This is a smaller example; there are a dozen and most are much longer. There's a whole lot of constant duplication and imports.

But this pattern predates using Typescript, and actually in most places where you have a tight typescript type it will complain if you have an incorrect type anyway, so we could get rid of a lot of unnecessary indirection.

The main thing to watch out for is there are a few places where a tighter enum is used in a string field. There you'd want to make an explicit const with the tighter type to verify and typecheck, and then use the const in the broader field.

Using Zod to drive the enum will make it possible to iterate through the various legal values easily, instead of doing a weird indirection of having an object with each key.

Noticed while working on #670.

jkomoros added a commit that referenced this issue Nov 11, 2023
jkomoros added a commit that referenced this issue Nov 11, 2023
In the vast majority of cases where the type is already tight enough, it can just be replaced by the
string value.  Also add cardTypeFilter, which is a convenient type check for the other cases.

Part of #673.
jkomoros added a commit that referenced this issue Nov 12, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
jkomoros added a commit that referenced this issue Nov 13, 2023
This will make it easier to clean up ReferenceType and TextField.

Part of #673.
jkomoros added a commit that referenced this issue Nov 14, 2023
So if they're used from a non-typescript context (like tests) they'll fail immediately.

Part of #674. Part of #673.
jkomoros added a commit that referenced this issue Nov 14, 2023
jkomoros added a commit that referenced this issue Nov 14, 2023
jkomoros added a commit that referenced this issue Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant