This would be valuable info to know when deciding whether or not to integrate this component.
The only payload size that matters is post-minification and post-gzip, and that depends on your app's settings… typically you'd have a process of determining your app's bundle size diffs on a PR prior to merging to master.
Additionally, if you import the main entry point, you'll get the entire package, but if you deep-import only the components you need, you'll have less code (ie, manually tree-shaking, which is always a best practice). This means there's no generic answer unless we provide a table of every entry point, and its size, and even then the size won't be generic due to the above paragraph.
We will also be digging into ways to minimize the size very soon. Specifically for something like the DateRangePicker, even when the DayPicker is not visible, it will still be loaded. There are some improvements we could do in those spheres that we will be working on for our benefit. :)
If you do care about this, we do recommend deep-importing only the packages you need, ie.
import DateRangePicker from 'react-dates/lib/components/DateRangePicker`;
over using the main entry point like below
import { DateRangePicker } from 'react-dates';
Both work, but the latter is a bit easier while the former is able to made more performant depending on your build.
Most helpful comment
We will also be digging into ways to minimize the size very soon. Specifically for something like the
DateRangePicker, even when theDayPickeris not visible, it will still be loaded. There are some improvements we could do in those spheres that we will be working on for our benefit. :)If you do care about this, we do recommend deep-importing only the packages you need, ie.
over using the main entry point like below
Both work, but the latter is a bit easier while the former is able to made more performant depending on your build.