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

A good DX for custom discriminants #43

Open
paarthenon opened this issue Jul 21, 2022 · 0 comments
Open

A good DX for custom discriminants #43

paarthenon opened this issue Jul 21, 2022 · 0 comments

Comments

@paarthenon
Copy link
Owner

Custom discriminants (using kind instead of type) are pretty well supported with variantCosmos (see #17).

Now the task becomes—how should we include the most common variants (hehe) without tripling the bundle size?

Followup question—could/should we avoid collisions between that and the default variant exports? As in, if a user wants to leverage their own match function that operates on something other than type, then is it really a good idea for the top-level functions to get in the way?


Off the top of my head, there's the ability to do multiple packages... but I'm actually intrigued by the potential of creating multiple index pages and changing the default assumption to import from those. Basically, remove all the exports from "variant" except for variantCosmos, and then publish everything under subfolders.

import {variant, fields, VariantOf} from 'variant/type';
 
export const Animal = variant({
    cat: fields<{name: string, furnitureDamaged: number}>(),
    dog: fields<{name: string, favoriteBall?: string}>(),
    snake: (name: string, pattern: string = 'striped') => ({name, pattern}),
});
export type Animal = VariantOf<typeof Animal>;

However, this may make it difficult for autocomplete to know what to prioritize 🤷‍♀️. This needs testing. The current world where you import variantCosmos in one file and then have the rest of your app pull from your re-exported members isn't terrible (users tell me if I'm wrong), so this probably needs to be actively good to be worth it.

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