Working on ConsentBanner about react-dsfr HOT 8 CLOSED

Hi @lsagetlethias,
Happy to see you there,
I don't know if you remember, you invited me on your Deno Paris show some years back... anyway.

Thank you for this, ConsentBanner is a most awaited component.

I actually saved the "consent state" in localStorage with zustand persist. How do you prefer this state to be persisted?

Let's remain dependency free (beside tsafe) we can do it ourself. Localstorage seems like the way to go.

from react-dsfr.

Anyway be aware that we have to make this work with SSR.

from react-dsfr.

If we need reactifity (observable variable), in this codebase we use: https://github.com/codegouvfr/react-dsfr/tree/main/src/tools/StatefulObservable

from react-dsfr.

Here is your invite: https://github.com/codegouvfr/react-dsfr/invitations

from react-dsfr.

Hi
Many services use https://tarteaucitron.io/fr/ to manage the GDPR.
What do you think of integrating this library to manage cookies (mainly deletion during a refusal)?

from react-dsfr.

AmauriC/tarteaucitron.js#1089

from react-dsfr.

Imho, tarteaucitron should not be used for many reasons.
1/ As @garronej said, react-dsfr must remain dependency free as much as possible.
2/ To "properly" use this lib as a module, or easily handle version upgrade, a monthly subscription is required (https://tarteaucitron.io/fr/#:~:text=Toujours%20%C3%A0%20jour)
3/ This lib is not CSP friendly (Content Security Policies). Inline scripts and styles are injected.
4/ This lib is not React friendly by manipulating the dom a is, and tinkering with the window object.

The ConsentBanner is not meant to delete cookies or detect & deactivate services for you. It will only give you info about user consent or not.
Many services have their own opt out function. (e.g. Matomo) and they should be used in junction with the observed gdpr store.

If you need tarteaucitron, I suggest you to take a look at https://github.com/GouvernementFR/dsfr-theme-tarteaucitron instead of using the ConsentBanner.

from react-dsfr.

While all the points made by @lsagetlethias are correct we can also argue that:

1/ As @garronej said, react-dsfr must remain dependency free as much as possible.

While we try to remain depencency free we are open to provide specific integration with other library or framework. It's what we do with MUI, we do not have @mui/material as dependency but as an optional peer dependency (conceptually). As long as you have mui installed in your project you can import {} from "@codegouvfr/react-dsfr/mui";
We could theorically have a standalone export for the integration of tarteaucitron like import {} from "@codegouvfr/react-dsfr/tarteaucitron". I don't know if it's rellevent or not, the only thing is I've heard it pop here and there multiple time already and the name of the game for this library is to enable you to keep using what you are already using. The DSFR should not be a constraint but an enabler. I don't know this library in particular and maybe @lsagetlethias you are right, it's not a recommendable library but if pepoles are already using it well... It's like react-router, I don't recommend it but it's important to support it anyway.

2/ To "properly" use this lib as a module, or easily handle version upgrade, a monthly subscription is required (https://tarteaucitron.io/fr/#:~:text=Toujours%20%C3%A0%20jour)

Mui as a paid plan as well. It's not nessesarely a deal breaker.

3/ This lib is not CSP friendly (Content Security Policies). Inline scripts and styles are injected.

Ok now this is to take into consideration.

4/ This lib is not React friendly by manipulating the dom a is, and tinkering with the window object.

This is precisely the role of an integration library to smooth up thing like this.

from react-dsfr.