From 7108c158f21dbc74eafbbc23e9847fba5cc231b2 Mon Sep 17 00:00:00 2001 From: Charles de Dreuille Date: Fri, 30 Jan 2026 13:31:09 +0000 Subject: [PATCH] Remove requestAnimationFrame hack and use proper ESLint disable Replaced the requestAnimationFrame workaround with an explicit ESLint disable comment. The setState call in this effect is intentional and valid - it's syncing component state with localStorage when switching to the custom theme, which is a legitimate use case for effects. This is clearer and more maintainable than hiding the intent with requestAnimationFrame. Signed-off-by: Charles de Dreuille --- docs-ui/src/components/CustomTheme/customTheme.tsx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs-ui/src/components/CustomTheme/customTheme.tsx b/docs-ui/src/components/CustomTheme/customTheme.tsx index 3a4ae0edc8..532f2bab9d 100644 --- a/docs-ui/src/components/CustomTheme/customTheme.tsx +++ b/docs-ui/src/components/CustomTheme/customTheme.tsx @@ -73,10 +73,10 @@ export const CustomTheme = () => { storedTheme = defaultTheme; localStorage.setItem('customThemeCss', storedTheme); } - // Defer setState to avoid synchronous call in effect - requestAnimationFrame(() => { - setCustomTheme(storedTheme!); - }); + // This setState is intentional - we're syncing component state with localStorage + // when the user switches to the custom theme. This is a valid effect pattern. + // eslint-disable-next-line react-hooks/set-state-in-effect + setCustomTheme(storedTheme); updateStyleElement(storedTheme); } else { const styleElement = document.getElementById(