Bug/checkbox calendar sync state

[sean-brydon]

Fixes: https://github.com/calcom/cal.com/issues/8438

Move calendar switch to local state instead of waiting on async call to change value.

Before

After

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
cal	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 9, 2023 9:40am

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
ui	⬜️ Ignored (Inspect)	Visit Preview		May 9, 2023 9:40am

[github-actions[bot]]

📦 Next.js Bundle Analysis for @calcom/web

This analysis was generated by the Next.js Bundle Analysis action. 🤖

Three Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page	Size (compressed)	First Load	% of Budget (350 KB)
/apps/installed/[category]	276.85 KB	427.65 KB	122.19% (🟡 +0.26%)
/getting-started/[[...step]]	415.99 KB	566.79 KB	161.94% (🟡 +0.40%)
/settings/my-account/calendars	251.41 KB	402.2 KB	114.92% (🟡 +0.27%)

Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/-

[deploysentinel[bot]]

Current Playwright Test Results Summary

✅ 112 Passing - ⚠️ 1 Flaky

Run may still be in progress, this comment will be updated as current testing workflow or job completes...

(Last updated on 05/09/2023 09:56:05am UTC)

Run Details

Running Workflow PR Update on Github Actions

Commit: f567a95c8545fe0e9e7013eca4ff2f551fe659f9

Started: 05/09/2023 09:46:35am UTC

⚠️ Flakes

📄   apps/web/playwright/app-store.e2e.ts • 1 Flake

Test Case Results

Test Case	Last 7 days Failures	Last 7 days Flakes
App Store - Authed Browse apple-calendar and try to install Retry 1 • Initial Attempt	0.37% (1) 1 / 269 run failed over last 7 days	62.83% (169) 169 / 269 runs flaked over last 7 days

---

View Detailed Build Results

---

[Udit-takkar]

@sean-brydon this looks much better. should i close this PR https://github.com/calcom/cal.com/pull/8595 then ?

[sean-brydon]

@sean-brydon this looks much better. should i close this PR #8595 then ?

Yeah i believe this is a better approach

[vaibhav135]

I think @hariombalhara recommended to not use local states for this? check #8595

[sean-brydon]

@hariombalhara here is the example below without local state. (I dont like it)

I personally much prefer having the switch be responsive as soon as i click it but open to be convinced. This api call doesnt use trpc FYI

@Jaibles design feedback would be welcome here... You expect the switch to work as soon as you click it right

[hariombalhara]

@sean-brydon My reasoning for it is the same as there for the Save button(except that it has a possibly larger payload and can take more time). When you click on the Save button, there is a loader that runs because it is updating something. We wouldn't want save to be considered done when we know it can fail. There are 2 ways we are using toggles in the app.

• Here toggling it doesn't actually update anything unless you click the Save button later.

• Current case that we are discussing, where toggling it actually updates something. [This case is similar to the Save button] You mentioned that it's not using tRPC, but it's using react-query already so we can do an optimistic update to further improve the experience. That would then match the local state implementation in terms of responsiveness.

[sean-brydon]

@sean-brydon My reasoning for it is the same as there for the Save button(except that it has a possibly larger payload and can take more time). When you click on the Save button, there is a loader that runs because it is updating something. We wouldn't want save to be considered done when we know it can fail. There are 2 ways we are using toggles in the app.

• Here toggling it doesn't actually update anything unless you click the Save button later.

• Current case that we are discussing, where toggling it actually updates something. [This case is similar to the Save button] You mentioned that it's not using tRPC, but it's using react-query already so we can do an optimistic update to further improve the experience. That would then match the local state implementation in terms of responsiveness.

Sure i agree with that :) We can do this in a follow up - This is affecting customers now and would like to get this merged so we can get it in for the next retreat

[hariombalhara]

Sure @sean-brydon. Totally makes sense. It's a miss on my part that I didn't notice it's an important fix.

[sean-brydon]

Sure @sean-brydon. Totally makes sense. It's a miss on my part that I didn't notice it's an important fix.

No worries! The delay between api calls is (with no loading state also) is causing users to think the switch just doesnt work currently. Especially on slower connections.