Call For Feedback: Our Next Big Calendar

[cutterbl]

We all love Big Calendar. It covers a wide range of display scenarios, has support for low and high level component overrides, and can be used with a variety of localizers to allow us to use our preferred date/time manipulation library.

Big Calendar is a large, widely used Open Source component in the React community, with 175+k downloads weekly, and listed in every major 'React component listing' list you can find. We all need to thank @jquense and every contributor who has put time and effort in to moving Big Calendar forward for 130+ versions over the last seven years.

That said, React has grown and matured. Big Calendar hasn't had a true major update in some time. Most of it is still written with class components, only the Drag and Drop implementation uses a true context, there is very minimal memoization, and some things are so tightly coupled that even a minor change can have major ripple effects.

So the question becomes "What (and how) could we do better?" On the one hand, we want to continue to support React 16+ (not just the latest version), but on the other we want something more performant and extensible. Whatever we decide, we would likely introduce broad breaking changes.

So, if Big Calendar were to take that leap, what changes would we want to see that would make the efforts worth while for developers? And, who wants to help?

I'm asking for feedback here. Let's start a discussion. What's done well? What needs work? What are your suggestions to move Big Calendar into the next seven years?

[bu6n]

Thanks for this issue!
I started using react-big-calendar for a project, and it is really the only library that can do almost all I need.

The first thing that comes to my mind: Rewrite in (or better support for) TypeScript with the possibility to easily extend types (like Event). In a TypeScript project, it is quite a mess to integrate, and it would provide more type safety. Maybe I just haven't found a way to do this the right way until now...

Another thing would be the ability to display steps smaller than a minute, and optimizations when displaying big calendars with small steps. Displaying a week view with steps of a minute is not really possible at the time (maybe use lazy loading or something similar). I could live with steps of a minute if the height of the displayed events would still take the seconds into account (haven't figured that out yet), but it still would be a pain performance-wise.

Selecting and moving multiple events at the same time would also be something I would like to see (for example with right-click drag).

Maybe at last integrate a date picker to select the current displayed interval. This may be out of scope.

If there are too much new features, maybe it would make sense to fork the project? I'm thankful for the work of jquense, but I'm not sure this is the right place for the repo (because people still assume that he's maintaining the project).

I'm currently working on a project with react-big-calendar and if it turns out good, I may have little time to contribute more to the project, but it's too early to tell.

[tpict]

It would be nice if this future library could take a less opinionated approach to styling. This is a tricky thing. One of the hard parts of building a calendar is writing the layout CSS, so there's definitely value in shipping CSS rules with the library. The library could include hooks to generate CSS grid rules for the event container and for each event. That would be a nice middle ground: the hard part would be taken care of, and the user would be free to implement the remaining styles without contending with built-ins, using whichever means they like (CSS-in-JS etc).

I would encourage future projects to look at Downshift for a great example of a "headless" UI library. IMO it enables much more granular customization than the traditional "specify your own components" approach. The library could still ship with an example implementation of a component and an example CSS sheet.

[jquense]

If it was me i'd rewrite with hooks and typescript, and update to use now-well-supported-apis like position sticky and CSS grid to handle most of the layout. I'd also try and replace a lot of the localization stuff we a default based on using the Intl APIs. I'd rewrite DND using dndkit instead of react-dnd.

I don't honestly think i'd change the component composition model much. RBC was always intended to be "batteries included" which means you need to be fairly opinionated about a number of things for stuff to Just Work out of the box. Headless UIs are great (heck I am the author of such a library). However they do require consumers do a lot of work to make them usable and accessible. For something as complex as a Calendar i think that makes it a hard fit for that style of library. I do think that css-in-js is also not a great option for making the library accessible to the most number of people. Sass is a bit annoying definitely, but it's far-and-away the most popular CSS option in web dev still.

Ultimately tho, really depends what ya'll want out of the library, my original needs have long since disappeared so no need to listen to me :P

[vincaslt]

Typescript + headless.

[lomber1]

Currently, all localizers are bundled, which is a waste of space, I think they should be moved to separate package, something like @react-big-calendar/localizers. Pop ups should be handled by a user, not by calendar library, simply because somebody might want to use their own solution (this also eliminates a huge react-overlays package). In general, getting rid of unnecessary libraries like lodash will make a huge difference in bundle size. Also, better typescript support and more elegant custom styling.
As of new features, I think multiple calendars support would be nice, something like in Toast UI Calendar

[cutterbl]

This is a great beginning to the conversation, and I'd like to keep it going. First pass list, from what I understand, is:

• Typescript
• More granular step support
• CSS-in-JS and CSS refactoring
• Select and move multiple events
• Hooks
• Headless
• Retain/refine components architecture
• Intl API
• DnD refactor
• Externalize localizers
• Multi Calendar Support
• Remove/Extract Popover

There are some really good bits in here. Here are some of my thoughts. First, I think we can all agree that vX is going to be (should be) a fairly major departure. I don't think anyone will be able to upgrade their version and have it 'just work' without changes. While that would be nice, I just don't think that's possible while also making the necessary changes to move forward.

I also think a new base level monorepo repository may be in order. Not to take away from @jquense, who has been the steward for so long and done so much, but because the branching and large scale changes required would be near impossible in the current environment. It would be easier to segment addons as their own, independent packages (localizers, DnD, etc).

@jquense brought up using the Intl API in lieu of localizers. I think this is a good idea, at a base level, but that we still require (optional) localizers for full timezone support (at least for now, as they still aren't completely supported by the Locale API in all browsers, specifically the weekInfo, though this could change by the time vX is ready to ship). There's also all of the 'date math' that the localizers provide. Think there's some discussion still to be had here.

I'm more in line with @jquense on the 'headless' architecture question. It sounds good, but calendar layouts, ultimately, are far too complex to just provide some base examples. I do think, with a well architected (and exported, and documented...) hook and component architecture that a developer would have an easier time developing custom override components.

And (this one may be controversial), I think we should stop using JS Date objects as props. Being objects, and unless properly memoized by the developer, they force constant rerenders throughout the component tree. Also, as objects, they make it excessively difficult to memoize other calls down the component tree. Big Calendar is big, and performance can really become impacted in views displaying large numbers of events, especially when using DnD. Memoization is critical, especially in terms of effects and callbacks. I suggest that we move these props to using ISO 8601 date/time strings. Most developers would populate data with a database, and all of them have the capability of returning this format, with or without offset or in UTC (Z) format all being ISO 8601 compliant.

I know, for me, there are a lot of things here that are not immediately in my "wheel house". I don't (yet) know TypeScript, I've never created or managed a monorepo, and haven't yet used (beyond playing around) the Intl and Locale API's. I'm fairly good with architecture, planning, CSS and JS, but I'm far from perfect, and will definitely require some help.

[MattiaVio]

i can help in migrating it to functional component from class.
I'm not a typescript guy and that would add complexity and lot of more time from my developer point of view to the migration.
Let me know if i can help

[vanenshi]

The current Typescript file is old, take a look at @types/react-big-calendar
at least maintaining the types yourself will help a lot

[yungfu]

Allowing user to get current view date range like onRangeChange is very useful when loading events from a server. Giving Agenda view a range function property, not only the length property, or allowing user to specify month as a date range option.