Gestion du dark mode page par page

[maxgfr]

Bonjour,

Récemment je suis tombé sur use-case que je dois gérer qui semble rentrer en conflit avec la gestion du theme light / dark

Contexte

Nous avons des pages que nous transformons en widget intégrable par d'autres sites. Si un utilisateur est en dark mode configuré sur notre site internet via le dsfr et qu'il va sur le site d'un partenaire, automatiquement l'UI sera en dark. Nous souhaitant que certaines pages soit définies dans un theme bien particulier.

Implementation

Aujourd'hui nous utilisons une application en nextjs avec un app router, nous gérons les paramètres dsfr à l'intérieur de celle-ci. Le problème semble venir du defaultSchemeColor qui s'applique sur le theme également :

react-dsfr/src/next-appdir/getHtmlAttributes.tsx

Line 37 in c5353f6

[data_fr_theme]: defaultColorScheme

Ces paramètres (data-fr-theme, data-fr-scheme) figurent dans le html ce qui semble pas super simple comme approche, car la logique de theme se ferait au niveau du server-side au risque d'avoir un clignotement au chargement de la page

Solution

Serait-il intéressant de faire un overrideColorTheme qui est définit de manière exceptionnel pour forcer l'utilisation au niveau du getHtmlAttributes ?

Par défaut nous pouvons laisser la couleur issue du defaultSchemeColor

Si tel est le cas, ça serait intéressant de mettre en place de la doc si telle est le cas, car l'approche de modifier un élément dans le html tag signifie qu'on doit utiliser un tag header et donc possiblement un middleware pour injecter les bons paramètres si on suit cette approche. J'ai le lien d'une PR si vous voulez voir l'approche avec le header : https://github.com/SocialGouv/code-du-travail-numerique/pull/6275/files

Je passe sûrement à côté d'autres éléments, si vous avez des hints ou solutions je suis preneur

[enguerranws]

Désolé du délai de réponse @maxgfr , peut être que tu as déjà trouvé une solution.

Ça me semble être un cas particulier, je ne suis pas sûr que ça ait un intérêt dans la lib.

Si je reprends le besoin, c'est de donner la possibilité à un service tiers de pouvoir contrôler l'affichage d'un bout de votre app (via un iframe j'imagine).

Je pense que c'est une approche qui doit être faite au niveau de votre app. Par exemple :

• mettre à dispo un query param contenant l'info du thème (à votre partenaire de l'alimenter comme il faut)
• de votre côté, un useEffect qui écrase le data-fr-theme en fonction de la présence et de la valeur du query param souhaité dans l'url, utilisé sur les pages que vous souhaitez

[garronej]

@maxgfr As tu essayer https://github.com/codegouvfr/keycloak-theme-dsfr/blob/80584c07267d444fb7495125516d22af52fa0399/src/login/Template.tsx#L20 ?

Depuis recement ça devrais marcher pour ton usecase

Parce que maintenant si defaultColorScheme est changé, ça écrase la valeur persisté.

J'ai fait ça pour que les devs qui change le défault n'ai pas a clear le local storage pour voir l'effet mais ça doit couvrir aussi ton usecase du coup.

[maxgfr]

@garronej Merci du partage, je vais essayer de voir cette approche : https://github.com/codegouvfr/keycloak-theme-dsfr/blob/80584c07267d444fb7495125516d22af52fa0399/src/shared/getColorScheme.ts

J'étais initialement parti sur ce qu'avait proposé @enguerranws, mais en effet, le problème est que cela réinitialise le localStorage dans l'iframe

[maxgfr]

Avec l'approche qu'on a actuellement, c'est le queryParam qui va lancer le hook de changement de thème et donc réinitialisé le localStorage

[maxgfr]

ça serait intéressant de l'avoir dans le dsfr en native avec une approche de la sorte : https://github.com/codegouvfr/keycloak-theme-dsfr/blob/80584c07267d444fb7495125516d22af52fa0399/src/shared/getColorScheme.ts

je ne pense pas que je sois le seul dans ce use case