feat: Assign colors to events

[anikdhabal]

What does this PR do?

• Fixes [CAL-2791] Assign colors to events to make them easier to find in the booking overview #7507
• Fixes CAL-2791

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected)
• I have added a Docs issue here if this PR makes changes that would require a documentation change
• I have added or modified automated tests that prove my fix is effective or that my feature works (PRs might be rejected if logical changes are not properly tested)

How should this be tested?

• Are there environment variables that should be set?
• What are the minimal test data to have?
• What is expected (happy path) to have (input and output)?
• Any other important info that could help to test that PR

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't commented my code, particularly in hard-to-understand areas
• I haven't checked if my changes generate no new warnings

[vercel]

@anikdhabal is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

Thank you for following the naming conventions! 🙏 Feel free to join our discord and post your PR link.

[graphite-app]

Graphite Automations

"Add community label" took an action on this PR • (06/03/24)

1 label was added to this PR based on Keith Williams's automation.

"Add consumer team as reviewer" took an action on this PR • (06/03/24)

1 reviewer was added to this PR based on Keith Williams's automation.

"Add foundation team as reviewer" took an action on this PR • (08/11/24)

1 reviewer was added to this PR based on Keith Williams's automation.

[github-actions]

This PR is being marked as stale due to inactivity.

[Amit91848]

Amazing work so far @anikdhabal ! Found a small issue that should be fixed. Can you also fix the merge conflicts.

You select a specific colour for event type and save the event type. Now you toggle the colour settings off and on again, but don't save the event type. The colour reverts to its default value, becoming inconsistent with current state of event type. Ideally it should still be the colour previously saved as we did not make any changes to it. Attached a video for better understanding.

Recording.2024-06-28.230706.mp4

[github-actions]

This PR is being marked as stale due to inactivity.

[anikdhabal]

This doesn't match the designs in figma https://www.figma.com/design/UajFu4M1APhn2AywAEJkJr/New-Features?node-id=4673-355405&t=ih0GY2rAHb4Wc3wX-.

Hey @Udit-takkar , why do we need to create a different color picker component with limited colors when we already have one? I think the current picker provides more color options. Additionally, creating a new component would make the code larger, and the use case for that color component is only for the event type color picker. Lmk what you think

[Udit-takkar]

Hey @Udit-takkar , why do we need to create a different color picker component with limited colors when we already have one?

We can't allow any colour to be selected as we have to make sure it doesn't fail the WCAG Contrast guidelines https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast. Just confirm with @ciaranha once about the design and let me know

[anikdhabal]

Hey @Udit-takkar , why do we need to create a different color picker component with limited colors when we already have one?

We can't allow any colour to be selected as we have to make sure it doesn't fail the WCAG Contrast guidelines https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast. Just confirm with @ciaranha once about the design and let me know

Sure @Udit-takkar , and for WCAG contrast guidelines, we can add a check and display a message. I think in our code, we check the contrast for both dark and light modes in some components

[anikdhabal]

We can't allow any colour to be selected as we have to make sure it doesn't fail the WCAG Contrast guidelines https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast. Just confirm with @ciaranha once about the design and let me know

Ciaran confirmed that we can use the color picker that we should have

[sean-brydon]

Translation not loading

I was able to set this colour and didnt get an error

Created a replit for easier testing of this fn manually.

We may honestly need a light/dark mode colour selector if we're not going for a preset color pallets like in the designs.

[anikdhabal]

Hey @sean-brydon, the problem is that the way we handle the contrastCheck function is not optimal. The function is guaranteed to return a boolean, but we unnecessarily use it inside a try-catch block in every instance.

Before:-

After changes:-

And yes, it would be optimal to add a light and dark mode color selector.

[sean-brydon]

Nice one! Thanks for making them changes - much better behaviour now

Fixed

[anikdhabal]

Fixed the conflicts

[sean-brydon]

Tested again - this is a neat feature!

[github-actions]

E2E results are ready!

• Attempt #28356.1 results