You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
Custom discriminants (using
kind
instead oftype
) are pretty well supported withvariantCosmos
(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 thantype
, 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 forvariantCosmos
, and then publish everything under subfolders.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.
The text was updated successfully, but these errors were encountered: