iframe was great because we controlled our page context to style things
easily, handle assets easily.
But since it's not on the same domain as the services consuming it, it
implied configuration here and there. Also some behaviors were annoying
to implement (for example, keyboard navigation). I'm sure everything we
do is possible via iframe but I feel like I'll go from barrier to
barrier at every new thing we want to do…
I feel like, at the cost of handling style-conflicts, just rendering
everything in the real page context is more future-proof.
- allows us to easily differentiate the exposed components of the npm
package vs the dev-only ones
- allows the postcss config to purgecss correctly for production build,
we do not include the classes seen in the dev components
- buttons are now back to their default display mode (the one from
.fr-btn), we just change a bit the proconnect style to match figma
design while fixing the spacing issue at the bottom of the button there
was
utility classes are great but since these are meant to be reused easily
by copy/pasting the code I feel like having less clutter in the
classnames is better
- the tagline now has a wrapper in case we want to add other content
inside the white box
- we ditch the 50/50 column logic so that the tagline takes the space it
needs
- the CSS that included the DSFR excerpt we needed styled some base html
tags directly. It might collide with a service CSS already there. Now a
postcss plugin applies a CSS prefix to everything
- we output in the lib two DSFR file versions: one with prefixed
selectors, one raw.
- we have a static astro website under /website. It has the
implementation docs of the homepage/gaufre templates, and it handles the
few API endpoints (the gaufre js, backgrounds, logos)
- we have a vite app under /packages/integration. It has the react
components generating the homepage and the gaufre button, and their css.
Its used to generate an npm package
