Call For Feedback: Our Next Big Calendar

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?

[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.

[vincaslt]

Typescript + headless.