react-dsfr VS tss-react

GitHub Repo: https://github.com/codegouvfr/react-dsfr Storybook: https://react-dsfr-components.etalab.studio/?path=/story/%F0%9F%87%AB%F0%9F%87%B7-introduction--page

Great, don't hesitate to reach out in the discution section of the github repo. I love sharing my tips. https://github.com/codegouvfr/react-dsfr/discussions

My advice if you don't have a multi-million budget and you only need to support React is to start from MUI components. Components like Date pickers, or Autocomplete are complex and time consuming to code from scratch. First thing you want to do is to build a custom theme for MUI (example DSFR, Example OnyxiaUI) this will make the MUI components roughly match your design system out of the box. Then you can create your own components that are wrapper around MUI components and customize them until they match your design (Example). Trust me, we always underestimate the complexity of building base component from scratch. There are tons of things to consider, I don't even mention the accessibility concerns... Customizing MUI components is the quick win route.

Thank you ☺️ I mean it's open source so technically you can but legally you can't. If you publish a website using this lib you'll get it shut down by the French authorities.

If you want a real-world use case you can consider this function, it has a very opaque and complex return type that is inferred from the input it receives. Having type-level unit test for this function is very useful both for ensuring the return type is inferred correctly and as an implicit documentation.

Do you think it's totological to test the return type of this function?

Take for example this function, it's return type if very opaque. I'm very happy I'm able to test it.

This is much less precise than what my return type inferred from what the user gives me as input.

What I meant is that the lib provides the tooling to do CSS-in-JS if you so choose. But it's not at all mandatory. There is a fully type safe class system you can rely on. Internally no CSS-in-JS is used. I personally do love CSS-in-JS (I'm the author of TSS) but I understand the case against it.

I'm not big on splitting things in neat little modules. Before we had logic.js structure.htm, styles.css then React suggested that logic and structure should be in the same file, it was the right move. Styles, in my oppignion, should be done in JS as well as well. I think that queries shouldn't be mangled with the UI stuffs.

Real-life examples: 1, 2, 3

Material UI v5 brought some amazing updates, but switching from JSS to Emotion had an arguably nasty side-effect: it was no longer as straightforward to group your component styles in classes. Fortunately, a fantastic library emerged that allowed developers to not only reduce the extreme pain from migrating all their classes from v4's makeStyles to emotion, but to also to continue to writing classes in practically the same syntax, with wonderful TS type-safety. This library was tss-react, and it was one of my favorite open source discoveries of 2021.