-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DRAFT] Multi-booked event view #195
Conversation
…ts to overlap and nicer column separation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I liked the grid approach, as it provided an easy way to define columns and gaps between events. I also don't see any issue with many CSS classes, when they're properly formatted, sorted and wrapped 😅 But I'm also fine with using absolute positioning, as it solves overlapping much better. However, it introduces some new issues...
I currently have a hard time though to distinguish between different events:
Maybe we can use at least a little gap between calendar events or some kind of border?
Also overlapping appointments now have some border overlapping effects:
I guess we still need some kind of overlapping detection and give "higher" appointments a little offset... or I don't know 😅
Grid approach was handy, I just don't know how I feel about defining 1000+ rows per week day :P Every other web calendar I've seen uses absolute positions, so I think that should be good. I will discuss the overlap problem in this mornings meeting. Thanks for pointing that out! |
Well that is the beauty of grid: You only define the rows (doesn't matter how many), and only build actual dom elements for events (actual grid elements) 😇 |
@solangevalverde will figure this border problem out 👀 |
a186490
to
52307b0
Compare
This might become obsolete now with #274 right? |
Good point, I've got a copy locally if we still need it. Thanks! |
Fixes #70
An extreme edge case of multi-booking yourself:
In order to get this working nicely, I dropped the css grid approach, and just group events by start time and then set their
top
absolute value. Our calendar doesn't resize, so this is probably not a bad option. i haven't implemented it in daily view, as it wasn't as much of an issue there.It's still sort of ugly, but we just needed something better for the MVP. I didn't want to re-write the existing weekly calendar code, but I sort of did anyways lol. I'd like to re-work that insertEvents function so we don't have to duplicate the same code twice, and to get rid of that ugly order processor but it works for now. Also reduce the amount of classes on some of these divs lol.