Skip to content

fix(SF2.0): Properly show loading circle when changing schedules#3066

Merged
jlucytan merged 2 commits intomainfrom
jlt/fix/daily-schedules-responsiveness
Mar 31, 2026
Merged

fix(SF2.0): Properly show loading circle when changing schedules#3066
jlucytan merged 2 commits intomainfrom
jlt/fix/daily-schedules-responsiveness

Conversation

@jlucytan
Copy link
Copy Markdown
Contributor

@jlucytan jlucytan commented Mar 31, 2026

Scope

Asana Ticket: 📅🔎 Fix performance of Daily Schedule schedule-change

Implementation

After investigating, there are two potential causes for loading circle taking a while to appear:

  1. Latency between client and server, due to state management being server-side
  2. Doing a chained assignment requires the full chain to complete before updating, so loading does not appear until after the load request

1 would require a more involved change in how we do state management and is unlikely to be encountered, so I've not included a change in the behavior here.

The root of the issue as seen in QA is likely 2, since the folks who helped with QA shouldn't be encountering such high latency between a client and server. The fix is a fairly straightforward separation of the assignment into two parts, one for the async request for the schedule and one to set the loading status while the async request is performed.

Screenshots

No static visual change, observe change in when loading circle loads in

How to test

Copley on dev-green (or can check in prod) should have the undesirable behavior (loading circle/schedule change takes a while to appear after changing the schedule)
Copley on dev-blue should display the fixed behavior (loading circle should appear immediately after changing the schedule)

If the above does not make it clear, it's possible to exaggerate the issue locally to make it more obvious:

We can check that waiting for the assign is an issue by introducing a lengthy sleep in /Users/ltan/Documents/code/dotcom/lib/dotcom_web/live/schedule_finder_live.ex assign_service/2 (e.g. :timer.sleep(5000)) on the main branch and using the Daily Schedule selector (link to Copley for convenience) . Observe the 5 second delay (or however long you set) between selection, and the loading circle briefly flashing before quickly changing to the correct schedule.

You can verify the fix locally by putting the sleep in the same place on this branch. When using the selector, the loading circle should appear near immediately and stay for the duration of the sleep, then change to the schedule.

@jlucytan jlucytan requested a review from a team as a code owner March 31, 2026 13:56
@jlucytan jlucytan requested a review from thecristen March 31, 2026 13:56
@jlucytan jlucytan added the dev-blue Deploy to dev-blue label Mar 31, 2026
Copy link
Copy Markdown
Contributor

@lvachon1 lvachon1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is very good to know, thanks for showing us this smarter pattern!

@jlucytan jlucytan enabled auto-merge (squash) March 31, 2026 19:47
@jlucytan jlucytan merged commit 63f3519 into main Mar 31, 2026
16 of 17 checks passed
@jlucytan jlucytan deleted the jlt/fix/daily-schedules-responsiveness branch March 31, 2026 19:54
@github-actions github-actions Bot removed the dev-blue Deploy to dev-blue label Apr 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants