Replies: 19 comments
-
@gpbl do you know what functions v8 will need? I mean the logical operators it needs (e.g. adding N days to a given day). This list can then be mapped to library functions (e.g. Other options I can think of:
|
Beta Was this translation helpful? Give feedback.
-
I think the main issue here are localization-based calculations (eg first day of the week). I’d go with date-fns and study the problem with a lower priority. There are many options out there! I really want to push date-fns, it is good for the ecosystem. Different approaches can be tried after the release. But i’d better discuss real use cases like yours first... |
Beta Was this translation helpful? Give feedback.
-
What do you mean by "real use cases" in this context? I also think |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
@dmtrKovalenko in the case where Note that I haven't referenced the |
Beta Was this translation helpful? Give feedback.
-
The main problem is how we can share them to be replaceable by user and get rid of object with functions. 🤷♂️ I don’t know |
Beta Was this translation helpful? Give feedback.
-
You can always supply them via props, I don't see anything wrong with that. <DayPicker renderDay={date => <div>{date.getDate()}</div>} ... /> If you want to use the default renderer you could implement a pattern similar to what office-ui-fabric-react uses: <DayPicker renderDay={(date, defaultRender) => defaultRender(date.getDate())} ... /> where @dmtrKovalenko I don't see any reason for an object with functions here, but I'm happy to learn why you think one is needed in the first place :). |
Beta Was this translation helpful? Give feedback.
-
The main idea of the date-io is that user can import the adapter, one time pass it as a prop and any component will work out of the box import DateFnsAdapter from 'yourLib/date-fns'
<DatePicker adapter={new DateFnsAdapter({ locale: ruLocale })} />
// it doesn't matter this can be a fabric function
<DatePicker adapter={makeDateFnsAdapter({ locale: ruLocale })} /> But how we can populate it as a tree shakable function? Only one way I can imagine -- each consumer of date-io will need to reexport needed functions as objects import { addDays, format, parse } from '@date-io/date-fns'
export default { addDays, format, parse } And then in the code use them exactly like date-fns functions. But I don't think that it worth it, personally I don't like date-fns in the javascript environment :) (In ReasonML - it's the best) So I think that the best way to handle it would be to split out the date-io into several independent classes or functions for Formatting, Parsing and Calculations. |
Beta Was this translation helpful? Give feedback.
-
You can always utilize React's Context in this case: const dateTimeFormat = new Intl.DateTimeFormat();
<DayPickerFormattingProvider format={dateTimeFormat.format)>
<DayPicker /> {/* this can be nested anywhere inside the Provider, so you could even wrap your whole App with a Provider and forget about it if you want to */}
</DayPickerFormattingProvider> I personally don't like the usage of Context for this very much. I'd much rather have a So I still don't see a reason for using |
Beta Was this translation helpful? Give feedback.
-
In case I am using Luxon for formatting and timezone management - I don't want to see 44kb of date-fns in my bundle. I`d better include 1.6kb of date-io adapter. |
Beta Was this translation helpful? Give feedback.
-
@dmtrKovalenko how is passing in props/using React Context not solving this issue? This way there's either no usage of |
Beta Was this translation helpful? Give feedback.
-
I think we are talking about different things :) |
Beta Was this translation helpful? Give feedback.
-
Is it possible to somehow use v8 without date-fns? We are using dayjs in our project, v7's formatDate and parseDate props are very convenient. I don't want to bring extra dependency. |
Beta Was this translation helpful? Give feedback.
-
@vvav3 Only if maintainers will choose the date-library-independent way of date library.
|
Beta Was this translation helpful? Give feedback.
-
We also use Day.js with React Day Picker, and we chose them both in part because of their small size and lack of dependencies. |
Beta Was this translation helpful? Give feedback.
-
@gpbl I just updated to beta today (ironically hoping for a smaller bundle size as per BundlePhobia). I'm in the same situation as above - using DayJS with DayPicker 7. Did this ever get resolved? Can we use |
Beta Was this translation helpful? Give feedback.
-
Since I have no time for that, I have no plan removing the date-fns dependency or switch to other date libraries. Here the options I've considered:
Those are the functions we are using now from
Maybe other developers could join the maintainers to help reducing the size of the bundle? |
Beta Was this translation helpful? Give feedback.
-
We are quite apprehensive upgrading to v8 as we also use dayjs and due to the size don't want to add date-fns. Has anything happened on this front since the last comment? |
Beta Was this translation helpful? Give feedback.
-
Hi here, resurrecting this old thread as we made some progress. Yes - DayPicker still requires The goal could be actually replace In version 9, I could extract the The module can be replaced by passing import * as intlDateLib from 'a-lib-using-intl';
<DayPicker dateLib={intlDateLib} /> This sort of dependency injection allows DayPicker to support Jalali calendar and UTC dates, thanks to some In conclusion, removing |
Beta Was this translation helpful? Give feedback.
-
DayPicker relies on some date manipulation functions to work. Until v8 I've been maintaining a custom set of utilities to keep the bundle size small.
I underestimated the difficulties working with dates and other abstractions required to support localization, so I decided to switch to
date-fns
.This choice is raising some valid concerns in the community, which I would like to collect here.
References:
Beta Was this translation helpful? Give feedback.
All reactions