| |

MarkUs: Scheduled Visibility (Frontend)

Making the backend feature usable.

PR #7717

The Work

Built the entire UI for scheduled visibility:

  • Visibility control with 3 options: Hidden, Visible, Scheduled
  • Flatpickr integration for datetime selection
  • Section-specific visibility table for per-section overrides
  • Responsive design โ€” vertical radio buttons on narrow screens
  • Controller param normalization โ€” ensuring consistent data from frontend
  • Frontend + controller tests
  • i18n locale files โ€” English translations for all new strings
  • Documentation PR for MarkUs Wiki

The Tricky Parts

Timing-related test flakes โ€” Date pickers are async. Tests that worked locally failed in CI because of timing differences. Fixed with proper waitFor patterns.

Form semantics โ€” When โ€œScheduledโ€ is selected, show the date pickers. When โ€œVisibleโ€ is selected, hide them and clear the values. Getting these state transitions right required careful JS.

Midnight edge cases โ€” โ€œVisible until Dec 31โ€ should mean โ€œvisible through Dec 31โ€, not โ€œhidden at 12

Dec 31โ€. UI had to make this clear.

What It Taught Me

Frontend/backend agreement โ€” The frontend sends data; the backend interprets it. They must agree on semantics or you get bugs.

Subtle UI choices break forms โ€” A checkbox that doesnโ€™t clear a hidden field. A date picker that doesnโ€™t reset on option change. Small things cause big confusion.

Controller input sanitization โ€” Never trust frontend data. Normalize it in the controller.

Matching existing design systems โ€” MarkUs has constraints. New UI must fit, not stand out.

Debugging date pickers at 1 AM โ€” Sometimes thatโ€™s just the job.

Seeing instructors finally use this feature felt surreal.