Different height calculation

Hello, first off congratulations for this great component!

Now, i have an issue with the calendar height. Not with not seeing anything like so many other issues around here (i did read the docs 😃 ), but with why the height is required and must be fixed. I’m guessing this is because you calculate the row height depending on the container height, then display as many events in each row as they fit. The rest go in the +1 more links in each cell. And that’s fine.

What i’d like more though, would be to specify a min/max number of concurrent events to display (let’s say 3/5). Now, if a row has 0 to 3 events in a cell, it would render 3 event slots in order to give the entire row a nice appearance. If there are more than 5 events in a cell, it would render the first 5 and put the rest under the ‘+1 more’ link as it already does (same appearance, but kinda different meaning as you can see). Rows with 3 to 5 concurrent events would take the corresponding height to fit them all but no more.

Cons:

• this implies changing the mindset a bit: no more calculating heights depending on container, but let container occupy the height of its children. This might be a lot easier said than done, depending on how deep the fixed height assumption is hard-coded into the component (i didn’t have time to look through the code yet). But, i’m confident it’s not impossible to implement, nor that it would bring many (if any) disadvantages. If anything, it should skip quite some height calculus.

Pros:

• it relieves the calendar component from dealing with scroll (now it reserves a bit of space on the right for the scrollbar). That would become the user’s concern, with multiple solutions to choose from depending on the desired look & feel they’re going for.
• week/day/agenda views would also look good (better imo) integrated with the page’s scroll instead of scrolling in a box. Sticky headers might become handy, but again, it becomes the user’s concern. Implementing optional out-of-the-box support for it would be a different matter.
• you could decide to make auto-height mode default with sensible defaults like 3/5 above (and opt-in into the fixed height mode via a prop) and avoid all the issues people have been submitting about not being able to see anything because they didn’t have any height set. It’s not your fault people aren’t paying attention to the docs, of course, but if so many people have this issue, i see it as an opportunity to make the library one step more intuitive to use than it already is.

I would implement this as an opt-in feature at first (something like autoHeight={{ min: 3, max: 5 }}, with autoHeight=false as default), then just making { min: 3, max: 5 } the default value if people use it frequently enough for it to make sense. What do you think?

Thanks for your time!

[steodor]

@jquense should i take your lack of reply as you’re not interested? Thanks again.

[ehahn9]

I don’t know if this is helpful, but I found wrapping the calendar in a flex container with flex-grow=1, height=0 “tricks” the calendar into seeing an explicit height, yet filling the parent completely. You can’t use height=100% because that’s still not explicit. You’ll also likely want the parent container to be height=100vh or some such. Again height=100% won’t help you there because your children will be implicitly sized. Just FYI in case that helps anyone!