Add comments

apps/web/lib/app-providers.tsx

@@ -106,6 +106,31 @@ const CalcomThemeProvider = (props: CalcomThemeProps) => {
   );
 };
 
+/**
+ * The most important job for this fn is to generate correct storageKey for theme persistenc.
+ * `storageKey` is important because that key is listened for changes(using [`storage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event) event) and any pages opened will change it's theme based on that(as part of next-themes implementation).
+ * Choosing the right storageKey avoids theme flickering caused by another page using different theme
+ * So, we handle all the cases here namely,
+ * - Both Booking Pages, /free/30min and /pro/30min but configured with different themes but being operated together.
+ * - Embeds using different namespace. They can be completely themed different on the same page.
+ * - Embeds using the same namespace but showing different cal.com links with different themes
+ * - Embeds using the same namespace and showing same cal.com links with different themes(Different theme is possible for same cal.com link in case of embed because of theme config available in embed)
+ * - App has different theme then Booking Pages.
+ *
+ * All the above cases have one thing in common, which is the origin and thus localStorage is shared and thus `storageKey` is critical to avoid theme flickering.
+ *
+ * Some things to note:
+ * - There is a side effect of so many factors in `storageKey` that many localStorage keys will be created if a user goes through all these scenarios(e.g like booking a lot of different users)
+ * - Some might recommend disabling localStorage persistence but that doesn't give good UX as then we would default to light theme always for a few seconds before switching to dark theme(if that's the user's preference).
+ * - We can't disable [`storage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event) event handling as well because changing theme in one tab won't change the theme without refresh in other tabs. That's again a bad UX
+ * - Theme flickering becomes infinitely ongoing in case of embeds because of the browser's delay in processing `storage` event within iframes. Consider two embeds simulatenously opened with pages A and B. Note the timeline and keep in mind that it happened
+ *  because 'setItem(A)' and 'Receives storageEvent(A)' allowed executing setItem(B) in b/w because of the delay.
+ *    - t1 -> setItem(A) & Fires storageEvent(A) - On Page A) - Current State(A)
+ *    - t2 -> setItem(B) & Fires storageEvent(B) - On Page B) - Current State(B)
+ *    - t3 -> Receives storageEvent(A) & thus setItem(A) & thus fires storageEvent(A) (On Page B) - Current State(A)
+ *    - t4 -> Receives storageEvent(B) & thus setItem(B) & thus fires storageEvent(B) (On Page A) - Current State(B)
+ *    - ... and so on ...
+ */
 function getThemeProviderProps({
   props,
   isEmbedMode,

packages/app-store/routing-forms/pages/routing-link/[...appPages].tsx

@@ -192,6 +192,7 @@ export const getServerSideProps = async function getServerSideProps(
     include: {
       user: {
         select: {
+          username: true,
           theme: true,
           brandColor: true,
           darkBrandColor: true,