m/paliad
1
0
Fork 0
Code Issues 152 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Align calendar-view rendering between Events/Termine page and Custom Views' calendar view type #55

New Issue
Open
opened 2026-05-20 11:59:25 +00:00 by mAi · 1 comment
mAi commented 2026-05-20 11:59:25 +00:00
Collaborator
Copy Link

Trigger

m 2026-05-20 13:58:

the calendar views in Events / Termine are different than in the custom views calendar view type. That should be aligned!

Current state (verify in design)

  • /events (Termine) has its own calendar rendering — likely in frontend/src/appointments-calendar.tsx or client/appointments-calendar.ts.
  • Custom Views (the user_views system that lets users define their own filter+view combos) supports a 'calendar' view type — separate calendar component, possibly with different month-grid / week-grid / day-grid layouts.
  • m sees the two as visually / behaviourally distinct and wants them to converge.

What to do

  • Audit the two calendar surfaces: which CSS, which TS module, which event-rendering helper.
  • Pick the canonical one (likely the Custom Views renderer if it's the more recent / general one).
  • Refactor the Termine calendar to use the canonical renderer. Drop the duplicate code path.
  • Visual + interaction parity: event tile shape, color, click behaviour (navigate to detail), today-highlight, weekday header.
  • Both surfaces filter events by the same shape (date range, project filter, type filter) so they can share the data-loader.

Out of scope

  • Brand-new calendar features (drag-to-create, week-resize, etc.) — alignment first, expansion later.
  • Changing the rest of /events outside the calendar view.

Role

inventor → coder if the canonical-renderer choice involves API contract changes; coder direct if it's purely a refactor to call the same module. Inventor probably warranted because both surfaces are non-trivial.

## Trigger m 2026-05-20 13:58: > the calendar views in Events / Termine are different than in the custom views calendar view type. That should be aligned! ## Current state (verify in design) - `/events` (Termine) has its own calendar rendering — likely in `frontend/src/appointments-calendar.tsx` or `client/appointments-calendar.ts`. - Custom Views (the `user_views` system that lets users define their own filter+view combos) supports a 'calendar' view type — separate calendar component, possibly with different month-grid / week-grid / day-grid layouts. - m sees the two as visually / behaviourally distinct and wants them to converge. ## What to do - Audit the two calendar surfaces: which CSS, which TS module, which event-rendering helper. - Pick the canonical one (likely the Custom Views renderer if it's the more recent / general one). - Refactor the Termine calendar to use the canonical renderer. Drop the duplicate code path. - Visual + interaction parity: event tile shape, color, click behaviour (navigate to detail), today-highlight, weekday header. - Both surfaces filter events by the same shape (date range, project filter, type filter) so they can share the data-loader. ## Out of scope - Brand-new calendar features (drag-to-create, week-resize, etc.) — alignment first, expansion later. - Changing the rest of `/events` outside the calendar view. ## Role **inventor → coder** if the canonical-renderer choice involves API contract changes; **coder direct** if it's purely a refactor to call the same module. Inventor probably warranted because both surfaces are non-trivial.
mAi self-assigned this 2026-05-20 11:59:26 +00:00
mAi commented 2026-05-20 13:23:51 +00:00
Author
Collaborator
Copy Link

Shipped via bohr; merged at https://mgit.msbls.de/m/paliad/commit/82ecbe3. Live after Dokploy deploy. ~700 LOC removed, ~100 added — single canonical mountCalendar() module replaces three implementations.

Shipped via bohr; merged at https://mgit.msbls.de/m/paliad/commit/82ecbe3. Live after Dokploy deploy. ~700 LOC removed, ~100 added — single canonical mountCalendar() module replaces three implementations.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#55
No description provided.
Delete Branch "%!s()"

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?