tss-react VS tsafe

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.

You can still use makeStyles with tss-react, as documented here: https://mui.com/guides/migration-v4/#2-use-tss-react. I've used it and it seemed to work quite well.

tss-react

Hello, This is a use case for tsafe, a utility that let you make assertions on types.

Zod is a solution for generating validators. I used to be reluctant to use it because I like to declare my types with the TypeScript syntax. I am not satisfied by getting the type inferred from the validator. The solution I found is to use tsafe, a utility that enables to make sure that two types are equals. With this solution you'll have to declare your type twice, once with the TypeScript syntax and once when declaring your zod parser but you are garentied that if you update your type and forget to update the corresponding zod parser your app won't build.

tsafe.dev

Hi, Checkout tsafe. It enables to test types definition. Checkout this GIF in particular. Let's say for example that we have an objectFromEntries function and we want to test it typewise, we can do: ```typescript import { objectEntries } from "../myObjectFromEntries"; import { assert } from "tsafe";

`Object.fromEntries()`, `Object.entries()` and `Object.keys()` are barely usable when in a TypeScript codebase because their return type are very vague. [tsafe](https://github.com/garronej/tsafe) features three new utilities: [objectFromEntries()](https://docs.tsafe.dev/objectfromentries), [objectEntries()](https://docs.tsafe.dev/objectentries) and [objectKeys()](https://docs.tsafe.dev/objectkeys), functionally equivalent to their built-in counterpart but featuring much better return types.

Three GIFs to convince you that you need tsafe in your life: