react-dsfr VS ts-pattern

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.

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?

ts-pattern has been a decent band-aid for the lack of native pattern matching, but obviously has downsides that could be avoided if it was built into the language.

https://github.com/gvergnaud/ts-pattern

ts-pattern

With how powerful the type system is you can implement pattern matching via a library pretty convincingly, https://github.com/gvergnaud/ts-pattern is definitely the go-to. That being said pattern matching is hardly a requirement for being ok for implementing compilers.

https://github.com/gvergnaud/ts-pattern might help

There's a proposal to add something like that to JavaScript but it's been stuck in limbo since 2017 although there are libraries like ts-pattern which implement it already.