webxdc/calendar
13
9
Fork
You've already forked calendar
3

improve calendar #151

Merged
jackaperkins merged 60 commits from ndh/calendar:improve-calendar into main 2026年03月26日 15:42:02 +01:00
Owner
Copy link

As discussed with @jackaperkins this PR now holds all changes including the e2e tests to have the full picture.

See the commit list for all changes/features introduced with this PR

Here the basic new features:

  • event list with filter
  • week view
  • adapt height to event duration in week view
  • year view
  • recurring events
  • full day events
  • start/end date validation
  • e2e tests for chromium & mobile browsers

This PR was bootstrapped with AI and manually reviewed and tested before asking for review

As discussed with @jackaperkins this PR now holds all changes including the e2e tests to have the full picture. See the commit list for all changes/features introduced with this PR Here the basic new features: - event list with filter - week view - adapt height to event duration in week view - year view - recurring events - full day events - start/end date validation - e2e tests for chromium & mobile browsers This PR was bootstrapped with AI and manually reviewed and tested before asking for review
Reviewed-on: ndh/calendar#1 
- persist view mode
- more buttons to enable tab focus
- no dayscreen after editing days
Add e2e tests to README
Some checks failed
CI / build (pull_request) Failing after 32s
ddef586c46 
Fix e2e:ui issue
fix: jump to selected month for week view
All checks were successful
CI / build (pull_request) Successful in 34s
b336e08a0b

Overall looks okay! i would suggest moving a lot of the functions in the calendar class out to another file, all of the ones that don't need a reference to self and just process data rather than dealing with the app's ui lifecycle.

Overall looks okay! i would suggest moving a lot of the functions in the calendar class out to another file, all of the ones that don't need a reference to self and just process data rather than dealing with the app's ui lifecycle.
Author
Owner
Copy link

@jackaperkins wrote in #151 (comment):

Overall looks okay! i would suggest moving a lot of the functions in the calendar class out to another file, all of the ones that don't need a reference to self and just process data rather than dealing with the app's ui lifecycle.

Yes to me it seems also refactoring the huge class would be the next step, but that would be even more confusing to track the changes to the previous state.

So if you agree I would refactor the huge file and then we could start asking for manual tests in the webxdc channel after you reviewed/approved it?

@jackaperkins wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11156321: > Overall looks okay! i would suggest moving a lot of the functions in the calendar class out to another file, all of the ones that don't need a reference to self and just process data rather than dealing with the app's ui lifecycle. Yes to me it seems also refactoring the huge class would be the next step, but that would be even more confusing to track the changes to the previous state. So if you agree I would refactor the huge file and then we could start asking for manual tests in the webxdc channel after you reviewed/approved it?

All the changes flatten out in the PR diff view so I think it won't hurt to factor those functions out in the end. Sounds good!

All the changes flatten out in the PR diff view so I think it won't hurt to factor those functions out in the end. Sounds good!
Reformat comments
Some checks failed
CI / build (pull_request) Has been cancelled
de4491422b

I'm a bit confused about what's happened now.
My idea was for functions with simple arguments and return types (for example comparing two dates and returning a bool) to be separated out into another file and just called wherever needed. Those functions were indeed moved but seem to still be "wrapped" with an identical call in the calendar class:

Lines 676 to 704 in de44914
parseIcsDateString(dateStr) {
return parseIcsDateString(dateStr);
}
compareDatesBefore(y1, m1, d1, y2, m2, d2) {
return compareDatesBefore(y1, m1, d1, y2, m2, d2);
}
areDatesEqual(y1, m1, d1, y2, m2, d2) {
return areDatesEqual(y1, m1, d1, y2, m2, d2);
}
isWholeDayEvent(event) {
return isWholeDayEvent(event);
}
isTimedEvent(event) {
return isTimedEvent(event);
}
isMultiDayEvent(event) {
return isMultiDayEvent(event);
}
categorizeWeekEvents(weekEvents) {
return categorizeWeekEvents(weekEvents);
}
eventSpansDay(event, year, month, day) {
return eventSpansDay(event, year, month, day);
}
// calendar-event-editor.js wrappers
updateDayDropdown(d, m, y) {
return updateDayDropdown(d, m, y);
}

Unfortunately the inverse case also seems to have this problem. Functions that are closely associated with the calendar class (like updating some events data) were also factored out and wrapped in the same way, making it harder to read them than before because of rebinding the "this".

I'm a bit confused about what's happened now. My idea was for functions with simple arguments and return types (for example comparing two dates and returning a bool) to be separated out into another file and just called wherever needed. Those functions were indeed moved but seem to still be "wrapped" with an identical call in the calendar class: https://codeberg.org/webxdc/calendar/src/commit/de4491422bdb68d0331484b4093c17654758a2b7/js/calendar.js#L676-L704 Unfortunately the inverse case also seems to have this problem. Functions that are closely associated with the calendar class (like updating some events data) were also factored out and wrapped in the same way, making it harder to read them than before because of rebinding the "this".
Contributor
Copy link

Beautiful work! Is there anything I can help out with to review and/or test?

Beautiful work! Is there anything I can help out with to review and/or test?
Author
Owner
Copy link

@jackaperkins wrote in #151 (comment):

I'm a bit confused about what's happened now. My idea was for functions with simple arguments and return types (for example comparing two dates and returning a bool) to be separated out into another file and just called wherever needed. Those functions were indeed moved but seem to still be "wrapped" with an identical call in the calendar class:

Ok, seems the refactoring step mixed some stuff up. I will have a look later.

@jackaperkins wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11214223: > I'm a bit confused about what's happened now. My idea was for functions with simple arguments and return types (for example comparing two dates and returning a bool) to be separated out into another file and just called wherever needed. Those functions were indeed moved but seem to still be "wrapped" with an identical call in the calendar class: Ok, seems the refactoring step mixed some stuff up. I will have a look later.
Author
Owner
Copy link

@rtn wrote in #151 (comment):

Beautiful work! Is there anything I can help out with to review and/or test?

Testing would be appreciated. But I will first clean up some stuff that happened in the refactoring

@rtn wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11214961: > Beautiful work! Is there anything I can help out with to review and/or test? Testing would be appreciated. But I will first clean up some stuff that happened in the refactoring
- consistent grouping of functions by topic
- extract day view to own file
- remove event-query file
- extract event util functions in own file
- avoid wrapper & other overhead
- avoid validating end time too early
- show day panel on month view day click
- move hamburger menu to the right
- replace inline styles
- fix font-sizes
test: adapt tests to direct create event behaviour
Some checks failed
CI / build (pull_request) Has been cancelled
430e04108a 
- in month view a click on a day cell opens immediately the create event
 dialog, not the day screen (if there are no events yet on that day)
Improve header controls for mobile
Some checks failed
CI / build (pull_request) Has been cancelled
29b163c36c
Author
Owner
Copy link

Ok, after fixing and improving a lot of small issues and another refactoring I consider this now ready for review and testing.

I think the app still needs some UI/design improvements but should be a huge improvement already to the existing app.

For easy testing you can download the app here and add it as file to deltachat.

Ok, after fixing and improving a lot of small issues and another refactoring I consider this now ready for review and testing. I think the app still needs some UI/design improvements but should be a huge improvement already to the existing app. For easy testing you can download the app here and add it as file to deltachat.
59 KiB
fix: avoid cut off for week time slot
Some checks failed
CI / build (pull_request) Failing after 36s
df1a19194f

@ndh heya looks like the tests are failing, but otherwise i'd merge if they pass!

@ndh heya looks like the tests are failing, but otherwise i'd merge if they pass!
Fix prettier issue
All checks were successful
CI / build (pull_request) Successful in 35s
ca30703e7d

FYI it always has horizontal scroll

image

FYI it always has horizontal scroll ![image](/attachments/5870e66c-8530-4c70-86f2-b894ae936713)
WofWca left a comment
Copy link

Overall - I heard that one of the most important functions of these "official" apps (the ones in the WebXDC org) is to serve as example apps for others to take as references. That is why https://codeberg.org/durian/editor was forked and submitted separately.
Are we OK with turning this app into a giant vibe-coded blob?
But yes, functionality seems to have been improved.

Overall - I heard that one of the most important functions of these "official" apps (the ones in the WebXDC org) is to serve as example apps for others to take as references. That is why https://codeberg.org/durian/editor was forked and submitted separately. Are we OK with turning this app into a giant vibe-coded blob? But yes, functionality seems to have been improved.

@WofWca wrote in #151 (comment):

Overall - I heard that one of the most important functions of these "official" apps (the ones in the WebXDC org) is to serve as example apps for others to take as references. That is why https://codeberg.org/durian/editor was forked and submitted separately. Are we OK with turning this app into a giant vibe-coded blob? But yes, functionality seems to have been improved.

I'm on the fence myself about the size of the app here, any more and i would say it should be rewritten using some kind of reactive UI library. A fully featured calendar has a lot more UI logic than the other webxdc apps and the code should probably reflect that well. On the other hand the number of features a simple calendar app can be expected to have is limited and static so I would hope this PR would get us most of the way to "finished".

@WofWca wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11629237: > Overall - I heard that one of the most important functions of these "official" apps (the ones in the WebXDC org) is to serve as example apps for others to take as references. That is why https://codeberg.org/durian/editor was forked and submitted separately. Are we OK with turning this app into a giant vibe-coded blob? But yes, functionality seems to have been improved. I'm on the fence myself about the size of the app here, any more and i would say it should be rewritten using some kind of reactive UI library. A fully featured calendar has a lot more UI logic than the other webxdc apps and the code should probably reflect that well. On the other hand the number of features a simple calendar app can be expected to have is limited and static so I would hope this PR would get us most of the way to "finished".
Author
Owner
Copy link

@WofWca wrote in #151 (comment):

FYI it always has horizontal scroll

image

I don't see any horizontal scroll, neither on my phone nor in desktop:

image

Can you be more specific where you see it?

@WofWca wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11628091: > FYI it always has horizontal scroll > > [![image](/attachments/5870e66c-8530-4c70-86f2-b894ae936713)](/webxdc/calendar/attachments/5870e66c-8530-4c70-86f2-b894ae936713) I don't see any horizontal scroll, neither on my phone nor in desktop: ![image](/attachments/832469d3-48bf-41f0-b2d7-ec72e36bd4aa) Can you be more specific where you see it?

I don't see any horizontal scroll, neither on my phone nor in desktop:

Maybe this only happens on Windows, where the scroll-bars actually take space (and aren't just overlay), and maybe only on higher zoom levels.
Can be reproduced for me by opening a fresh app and clicking on any date.

> I don't see any horizontal scroll, neither on my phone nor in desktop: Maybe this only happens on Windows, where the scroll-bars actually take space (and aren't just overlay), and maybe only on higher zoom levels. Can be reproduced for me by opening a fresh app and clicking on any date.
Author
Owner
Copy link

@WofWca wrote in #151 (comment):

Overall - I heard that one of the most important functions of these "official" apps (the ones in the WebXDC org) is to serve as example apps for others to take as references.

Yes, that's one of the reasons why this PR introduces e2e tests

Are we OK with turning this app into a giant vibe-coded blob?

Can you be more specific? Where do you see a "blob"? I reviewed the code, jackaperkins reviewed it and it is mentioned that this was bootstrapped with AI.

So I would say we should care for arguments like maintainability, code structure & architecture but not a general "vibe-coded blob" concern.

@WofWca wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11629237: > Overall - I heard that one of the most important functions of these "official" apps (the ones in the WebXDC org) is to serve as example apps for others to take as references. Yes, that's one of the reasons why this PR introduces e2e tests > Are we OK with turning this app into a giant vibe-coded blob? Can you be more specific? Where do you see a "blob"? I reviewed the code, jackaperkins reviewed it and it is mentioned that this was bootstrapped with AI. So I would say we should care for arguments like maintainability, code structure & architecture but not a general "vibe-coded blob" concern.
Author
Owner
Copy link

@WofWca wrote in #151 (comment):

I don't see any horizontal scroll, neither on my phone nor in desktop:

Maybe this only happens on Windows, where the scroll-bars actually take space (and aren't just overlay), and maybe only on higher zoom levels. Can be reproduced for me by opening a fresh app and clicking on any date.

Ok, if the height of the window is below 620px I also see it. So yes should be fixed

@WofWca wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11631034: > > I don't see any horizontal scroll, neither on my phone nor in desktop: > > Maybe this only happens on Windows, where the scroll-bars actually take space (and aren't just overlay), and maybe only on higher zoom levels. Can be reproduced for me by opening a fresh app and clicking on any date. Ok, if the height of the window is below 620px I also see it. So yes should be fixed

One bug: going to week or month view always takes me to february for some reason, but pressing "today" does bring me to the correct week.

One bug: going to week or month view always takes me to february for some reason, but pressing "today" does bring me to the correct week.
Author
Owner
Copy link

@jackaperkins wrote in #151 (comment):

@WofWca wrote in #151 (Kommentar):

Overall - I heard that one of the most important functions of these "official" apps (the ones in the WebXDC org) is to serve as example apps for others to take as references. That is why https://codeberg.org/durian/editor was forked and submitted separately. Are we OK with turning this app into a giant vibe-coded blob? But yes, functionality seems to have been improved.

I'm on the fence myself about the size of the app here, any more and i would say it should be rewritten using some kind of reactive UI library. A fully featured calendar has a lot more UI logic than the other webxdc apps and the code should probably reflect that well. On the other hand the number of features a simple calendar app can be expected to have is limited and static so I would hope this PR would get us most of the way to "finished".

I decided to stay with Vanilla Javascript to make it easier for anyone to contribute. I would say let's have an eye on the maintainability and if we consider this solution too bloated we could go for a react/svelte whatever solution.

@jackaperkins wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11630713: > @WofWca wrote in #151 (Kommentar): > > > Overall - I heard that one of the most important functions of these "official" apps (the ones in the WebXDC org) is to serve as example apps for others to take as references. That is why https://codeberg.org/durian/editor was forked and submitted separately. Are we OK with turning this app into a giant vibe-coded blob? But yes, functionality seems to have been improved. > > I'm on the fence myself about the size of the app here, any more and i would say it should be rewritten using some kind of reactive UI library. A fully featured calendar has a lot more UI logic than the other webxdc apps and the code should probably reflect that well. On the other hand the number of features a simple calendar app can be expected to have is limited and static so I would hope this PR would get us most of the way to "finished". I decided to stay with Vanilla Javascript to make it easier for anyone to contribute. I would say let's have an eye on the maintainability and if we consider this solution too bloated we could go for a react/svelte whatever solution.

Can you be more specific? Where do you see a "blob"?

So I would say we should care for arguments like maintainability

Well yes, that's the point. According to git ls-files | xargs wc -l excluding package-lock.json, the whole app currently consists of 2899 lines. This MR alone changes more than x2 that amount.
And the added code is pretty complex. I don't think we can call it a "simple" calendar app anymore in our README.

> Can you be more specific? Where do you see a "blob"? > So I would say we should care for arguments like maintainability Well yes, that's the point. According to `git ls-files | xargs wc -l` excluding `package-lock.json`, the whole app currently consists of 2899 lines. This MR alone changes more than x2 that amount. And the added code is pretty complex. I don't think we can call it a "simple" calendar app anymore in our README.
Author
Owner
Copy link

@jackaperkins wrote in #151 (comment):

One bug: going to week or month view always takes me to february for some reason, but pressing "today" does bring me to the correct week.

I think the reason is:
If you switch from month to week view it opens the week with the first day of the month you started from. ANd since weeks always start on Monday the week starts probably in the previous month.
If you then switch back to the month it opens the month of the first day of the week you just saw.

Tbd: what would be the expected behaviour?

@jackaperkins wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11631205: > One bug: going to week or month view always takes me to february for some reason, but pressing "today" does bring me to the correct week. I think the reason is: If you switch from month to week view it opens the week with the first day of the month you started from. ANd since weeks always start on Monday the week starts probably in the previous month. If you then switch back to the month it opens the month of the first day of the week you just saw. Tbd: what would be the expected behaviour?
Author
Owner
Copy link

@WofWca wrote in #151 (comment):

Can you be more specific? Where do you see a "blob"?

So I would say we should care for arguments like maintainability

Well yes, that's the point. According to git ls-files | xargs wc -l excluding package-lock.json, the whole app currently consists of 2899 lines. This MR alone changes more than x2 that amount. And the added code is pretty complex. I don't think we can call it a "simple" calendar app anymore in our README.

Yes - "simple" should be removed but more since we have many features now. I didn't read "simple" as "simple code" but "simple app". Concerning the huge MR: my first start was to ask for review commit by commit - but after discussing that with jackaperkins who agreed on doing the review, he said he would prefer to do the review of the final PR.

@WofWca wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11631553: > > Can you be more specific? Where do you see a "blob"? > > > So I would say we should care for arguments like maintainability > > Well yes, that's the point. According to `git ls-files | xargs wc -l` excluding `package-lock.json`, the whole app currently consists of 2899 lines. This MR alone changes more than x2 that amount. And the added code is pretty complex. I don't think we can call it a "simple" calendar app anymore in our README. Yes - "simple" should be removed but more since we have many features now. I didn't read "simple" as "simple code" but "simple app". Concerning the huge MR: my first start was to ask for review commit by commit - but after discussing that with jackaperkins who agreed on doing the review, he said he would prefer to do the review of the final PR.
Author
Owner
Copy link

And we should consider: the last commit was my typo fix in December 2024. So we have the choice: leaving the app as simple (and almost unusable) as it was or step forward adding many features that one would expect from a calendar app.

That was my motivation to do this PR the way I did it.

And we should consider: the last commit was my typo fix in December 2024. So we have the choice: leaving the app as simple (and almost unusable) as it was or step forward adding many features that one would expect from a calendar app. That was my motivation to do this PR the way I did it.
Author
Owner
Copy link

Let's list all findings from tests here:

  • horizontal scroll appears in edit form when only vertical scroll is needed
  • if a day has only recurring events the jump to event opens the create new event form instead the day panel
  • jumping forth and back from week to month view iterates the selected month backwards
  • event list filter: the year dropdown remains visible even after switching to this week, this month and all events
  • rename "Custom Range" to "Given Month"
Let's list all findings from tests here: - horizontal scroll appears in edit form when only vertical scroll is needed - if a day has only recurring events the jump to event opens the create new event form instead the day panel - jumping forth and back from week to month view iterates the selected month backwards - event list filter: the year dropdown remains visible even after switching to this week, this month and all events - rename "Custom Range" to "Given Month"
Author
Owner
Copy link

@ndh wrote in #151 (comment):

Let's list all findings from tests here:

  • horizontal scroll appears in edit form when only vertical scroll is needed
  • if a day has only recurring events the jump to event opens the create new event form instead the day panel
  • jumping forth and back from week to month view iterates the selected month backwards
  • event list filter: the year dropdown remains visible even after switching to this week, this month and all events
  • rename "Custom Range" to "Given Month"

These should be all fixed now.

We also have tests now for import/export

@ndh wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-11702637: > Let's list all findings from tests here: > > * horizontal scroll appears in edit form when only vertical scroll is needed > * if a day has only recurring events the jump to event opens the create new event form instead the day panel > * jumping forth and back from week to month view iterates the selected month backwards > * event list filter: the year dropdown remains visible even after switching to this week, this month and all events > * rename "Custom Range" to "Given Month" These should be all fixed now. We also have tests now for import/export

Looks good to me, did a bit more testing the latest version between devices. Last tiny detail but nice to get right is background color here not following dark mode correctly: image

i'd say if you fix that and let's merge and make a release!

Looks good to me, did a bit more testing the latest version between devices. Last tiny detail but nice to get right is background color here not following dark mode correctly: ![image](/attachments/da0e09c8-a604-4129-86c7-b057fc8aa3e1) i'd say if you fix that and let's merge and make a release!
Adapt styles
All checks were successful
CI / build (pull_request) Successful in 32s
845a0c4635
Author
Owner
Copy link

@jackaperkins wrote in #151 (comment):

Looks good to me, did a bit more testing the latest version between devices. Last tiny detail but nice to get right is background color here not following dark mode correctly: image

Should be fixed now

@jackaperkins wrote in https://codeberg.org/webxdc/calendar/pulls/151#issuecomment-12050505: > Looks good to me, did a bit more testing the latest version between devices. Last tiny detail but nice to get right is background color here not following dark mode correctly: [![image](/attachments/da0e09c8-a604-4129-86c7-b057fc8aa3e1)](/webxdc/calendar/attachments/da0e09c8-a604-4129-86c7-b057fc8aa3e1) > Should be fixed now
jackaperkins referenced this pull request from a commit 2026年03月26日 15:42:04 +01:00
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
webxdc/calendar!151
Reference in a new issue
webxdc/calendar
No description provided.
Delete branch "ndh/calendar:improve-calendar"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?