Call For Feedback: Our Next Big Calendar
cutterbl opened this issue · 50 comments
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?
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.
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.
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
Typescript + headless.
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
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
componentsarchitecture IntlAPI- 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.
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
The current Typescript file is old, take a look at @types/react-big-calendar
at least maintaining the types yourself will help a lot
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.
Sth I would like would be a built-in way to zoom-in and zoom-out. I've managed to do it by hand, but the scrollToTime props don't work well with it, so a lot of hand-work is needed
Hi everyone! This is a great library!
I think it is necessary to improve the documentation, not just the library itself.
Maybe more comprehensive and exploratory documentation would be helpful for everyone that tries to use it for the first time.
For example, I can not find a proper example of how components props works or what to put in there.
@Canopix Documentation is always a challenge. Our latest documentation is pretty comprehensive, including several dozen code examples, but you're right that this needs to be a critical focus area as we move forward. Documentation adjustments/additions are even part of the contribution guidelines.
@butermann What exactly do you mean by 'zoom-in and zoom-out'?
@cutterbl, I think it is super challenging to find a way to provide suitable documentation; I'm not saying that the current documentation is awful; on the contrary, it is pretty good.
But, I think that it is necessary to find a way to provide an incremental platform as documentation and a way to receive contributions, maybe creating a "LAB" section in the documentation where people can create pages with a good description, use case, and CodeSandbox example, in this way people can share how they use the library for specific use cases.
- What do you all think about using nx for monorepo management?
- What is everyone's preference for CSS-in-JS? SASS modules? styled-components? @emotion?
- While this project has focused on providing React "Big Calendar", what about structuring the monorepo in such a way that someone could contribute components for other frameworks as well, in the same fashion as tannerslinsley has done with the various TanStack projects?
- I like nx or turbo if you want something more straightforward (https://turborepo.org/).
- Styled components or emotion is fine
- This sounds nice but is it something that is requested as a use case frequently? I think this is a big feature to implement and involves a lot of architectural changes.
@butermann What exactly do you mean by 'zoom-in and zoom-out'?
In week view or day view, I would like to be able to show different slot sizes going from a minute to seeing the whole day. When changing the timeslots and step props (and also changing the height of the slots with a custom slotGroupPropGetter), I had issues with the scrolling not getting updated (if I'm scrolled to 6pm, I expect the calendar to stay at that position after changing step heights). Maybe it's on my side or maybe it just should be an example in the doc, but maybe it's also some problem in the library.
@Canopix My reasoning behind considering nx began with this chart, specifically relating to the last three items on the list. Use of the NX Console in VS Code helps to take a lot of the guesswork out of the setup, and the code gen bits are heavy timesavers. Plus they have a pretty nice plugin ecosystem.
Another feature could be support for Popovers on Events.
One of the big requirements on my end is a resource timeline (basically a horizontal version of the resource view rbc currently has). There are other implementations out there, but I would love to stick with rbc:
- https://fullcalendar.io
- https://www.bryntum.com/
- https://github.com/namespace-ee/react-calendar-timeline (this has the zoom functionality I think @butermann was talking about?)
While this project has focused on providing React "Big Calendar", what about structuring the monorepo in such a way that someone could contribute components for other frameworks as well, in the same fashion as tannerslinsley has done with the various TanStack projects?
@cutterbl @tannerlinsley thoughts on a possible collaboration on getting a calendar library into Tanstack? This would be a huge add.
Adding to TanStack would be a big project. But I’ve been curious about the “incubator” approach. I would require that it be as headless and framework-agnostic/adapter driven as possible. If those are your same goals, then we should have a chat! Join my discord or DM me. https://tlinz.com/discord
@cutterbl thoughts? I'm down to help when/where I can, but my bandwidth is pretty limited.
@tannerlinsley Appreciate the feedback. Wasn't suggesting adding to to TanStack, so much as taking a similar packaging approach
Eh, was worth a shot 🙂
Sorry for assuming! Keep cruising!
@tannerlinsley Cool that you considered it! And thanks for TanStack. Inspiration :)
Thoughts on headless: I think we absolutely make hooks available that a dev could, theoretically, completely write their own interface. That said, Calendar is 'Big' and complex. One of the advantages is the ability to implement 'out of the box'.
@cutterbl React Day Picker's new release seems to do a good job at this. They have the OOTB implementation, but you can swap out components very easily (with hooks to get relevant data and functionality): https://react-day-picker.js.org/guides/custom-components
From a beginner's view, the documentation is hard to navigate and understand. I'm using Matine which uses CSS in js for styling & theme and that adds another layer of difficulty to styling. It took me quite a bit of effort to figure out how to do event bg colors. I looked through codesandbox examples (not the best). I found eventWrapper comp being a solution but felt there had to be better ways which led me to eventPropGetter from another sandbox. Halfway through figuring that out, I finally saw in the docs the tiny show code button which is something that is easily missed since it isn't always there and is not near the top. The description/details are also very bare. I feel like having an easier way to change CSS is needed since I would imagine everyone would need to alter it to some degree. Even if they don't want to do very colorful things and extra stuff, just changing to dark mode makes the default calendar CSS unviable. Even the docs have a dark mode toggle as an example, and it shows the issues already. The "docs" tab auto-scrolling / showing the calendar is kind of odd, shouldn't it show the details on top first? Also shouldn't "docs" tab be first and not canvas?
It would be great if there was a more direct place to ask questions besides reactiflux discord, still trying to figure out how to change off month days bg, toolbar button bg and color, and table border/grid lines. My only idea to styling the toolbar is copying the source toolbar and changing it there. I don't even know how to approach off-month days, etc besides making an scss file but would have to figure out how to do theming in scss.
@SimonC989 Theming can be a pain point, and is something we should address in the next version. While the new documentation is robust, and Storybook provides greater flexibility and control, there are certain challenges that I haven't figured out yet (like making the Docs tab the default). Help and PR's are always welcome though ;)
👋 recently worked on a project that used this library. First off, thanks for making this available! It saved me a ton of time.
My current pain point is render performance when updating the events list. Currently we are loading up to 700 events in a month via paged api calls of 100 events a page. RBC re-renders each time we update the event list, and _this.renderWeek ends up taking 1+ seconds per render. I haven't looked into the implementation yet. It would be nice if updating the event list was "magically cheaper" :D
Thanks again for all the hard work on this library and thanks for letting me share.
We've created a Slack Workspace (< invite link) to build community. The #next channel is there to discuss the future of Big Calendar.
In week view, being able to drag events that span multiple days 🙏🏽
👍 for typescript and for react-dnd support. react-big-calendar is already great, I think these features would make it even more accessible for modern tooling/usecases
A focus on completely built-in touch support
Typescript + Headless, yes.
I don't think "Working out of the box" is such a benefit. It probably helps with spreading the word, since beginners can easily adopt it, and, I dunno, post on twitter. Works for hobby projects as well.
However, any mature (enterprise?) project most likely needs customization far beyond anything you could reasonably provide, and at that point the included "batteries" turn into rakes to step on.
As for breaking changes, go for it. We're still on 0.20.3 and I don't think we'll be able to upgrade even to the current version without a major rewrite 😆 (due to heavy customization)
Rewrite the component in TS, Functional components and focus on being able to override the actual components without having to touch the SAAS bits.
Make it as headless as possible. This is my major grip with the lib right now.
@cutterbl thanks for the huge amount of work that you put into this great library!
I agree with @kavdev that making this similar to the Tanstack approach would be hugely helpful, particularly in making the styling more headless and flexible. I would actually also love to see this package become part of that ecosystem, given how active the development is around it. In terms of having one really solid open source calendar library for the React (and potentially beyond) community to catalyze around, it would be a great move in my opinion. @cutterbl of course you are free to make independent decisions but this group teaming up with @tannerlinsley and co would be exciting imo
There's a lot here. @stunaz there's been little discussion on 'next' in the Slack group at all. Most discussion in Slack has been from newer devs looking for help.
While I think putting Big Calendar in the Tanstack would definitely help forward momentum, and have huge respect for everything that @tannerlinsley and others have done there, I worry about moving Big Calendar to a purely headless scenario. Calendars are hard. While the general display of a 'Month' or 'TimeGrid' (week,day) is not that bad, especially now with CSS Grid and subgrid, laying out events on these interfaces has a lot of pitfalls. How many can we display? Do they span across multiple days? How do we stack? And what about Drag and Drop selection and resizing? That, alone, is one of the biggest barriers
What I do see is a mix of scenarios. For React, I see a use of true Context and hooks for all of the core logic around Big Calendar, for things like slot metrics and groupings, event handlers and specific component props. Core logic, in this, is actually framework agnostic, so React bits would just funnel that logic from shared library resources. That way the same functionality could be added to other framework equivalents. These are things that advanced developers can use without using any of the included components, if they chose to do so.
But for those developers who don't have the skills to manage the complexities of Calendar/TimeGrid layout and/or Event layout, I think a set of hooks and components are critical, complete with the capability of replacing any component within the component tree.
And, maybe that is a way to break it down. Maybe Tanstack chooses to adopt a Calendar project, with all of that base logic and headless accessors, and Big Calendar, itself, becomes a separate UI consumer project? But that's really a question for @tannerlinsley. If it were to go that route, I'd be happy to contribute to both.