Defining version 4 of react-datetime

[arqex]

We've just released version 3 and we need to start thinking where we are going to with the next version of the library. I'd like to give the opportunity to anyone to collaborate with their code but also with their thoughts about how to make react-datetime better.

React-datetime is an old pal, it was created soon after React.js was published (can you remember React's mixins? react-datetime used them!) and that means that the library's base code was based in old patterns that, nowadays, no developer want to dive in.

So version 3 has been an effort to take react-datetime a bit to the present (we stopped using createClass) but the internals are still basically the same, trying to not to break the current API so much.

My view of version 4 is in the same direction, I really would like to:

• Port the library to typescript
• Update dev dependencies and dev tools
• Port the tests to react-testing-library and stop using snapshot testing

But also I would like to make the code better with features that has been requested for so long:

• Reduce the usage of components' state as much as possible
• Revamp the time picker
• Make moment.js a optional dependency by allowing to plug other time management libraries to give the functionality. Like date-fns (https://date-fns.org/).

These points are some objectives I have in mind, but they are not the roadmap for the version 4. This issue is just to let us discuss and define the roadmap together, so feel free to leave your comments with your thoughts!

[onlined]

Converting stateless components to functions would make them simpler, and it would be a good step for switching to hooks if this is desired.

+1 on making moment.js optional. It's very big and it doesn't give good results with tree shaking. And lastly, its development stopped.

[arqex]

Hey thanks for those insights @onlined

Currently there are 2 stateful components:

• DateTime
• TimeView

And 3 stateless:

• YearView
• MonthsView
• DaysView

I'm not against to turn the stateless class components into functions, but I think in that case we should extract some logic from them. When the functional components are big, like these ones, I feel that class components are more readable.

About the usage of hooks, I'm not a big fan of them for storing any state. I know that it's not a very popular opinion, maybe I'm too old school, but I believe in functional components when they are pure, stateless. Hooks just break that pureness making functions stateful. When I see functional components made of a bunch of function definitions inside of the main one, and multiple useState calls I think... this is exactly what the classes were created for.

I'm more interested in simplifying the state of the components first, and the migration to typescript second. That would make the collaboration much simpler to anyone.

Making moment.js optional would be like a dream! But I don't know event where to start from. Moment is so in the core of this library that we would need to update all the sources.

[onlined]

@arqex We think alike about function vs class components. I had just said the advantage about hooks in case you wanted to switch, it's not something that I like very much either.

I think the interface shouldn't depend on any date library, it should be based on native JavaScript Dates. For implementation, I recommend date-fns. It doesn't introduce new types, only utility functions. In addition, you include only the functions you use in the build. Actually, I don't like supporting Moment, even as optional, but it can be supported it if it's very important for some users.

[pleunv]

My wishlist:

• Accessibility
• Using modern refs instead of the legacy ones or useImperativeHandle for navigate/setViewMode would be nice. Had to jump through a few hoops to get v3 to play nice now with FC parents components.
• Another vote for eliminating moment or providing the option to swap it out with i.e. date-fns. Especially given that the moment project is in maintenance mode now.

[arqex]

Hey @pleunv thanks for your votes! I think accessibility is very important too, we have this issue to keep track of it
#415.

We are kind of moving away from imperaitive methods, but I agree that it would be easer for navigating than updating the internal viewDate object. I accept proposals in this field too.

[scott0730]

What about to replace moment with 'dayjs'?

[arqex]

It would be great to make a list with the functionality needed from moment and create a file with an abstraction of that functionality. We can call it dateManager or something similar.

Once we have it, it would be possible to implement the dateManager using moment, dayjs or date-fns or whatever other library. The developers could inject the library they are using in their project, and react-datetime would be agnostic.

[bl-nero]

https://github.com/jquense/react-big-calendar is an example case where abstracting out moment.js and date-fns works well. I would welcome this library to support a similar pattern.

[YPCrumble]

It looks like https://github.com/dmtrKovalenko/date-io might work as a wrapper around whichever date library a user chooses.