I even put right now this recommendation in my article! ;)
It's very nice of you! Much appreciated! :D
But surely it is not that big deal to adjust it :)
This is, infact, extremely hard to adapt this API to work with type inference. I'd say the types definitions represent 90% of the overall effort that went into developing tss-react.
Regarding SSR, you are not right, emotion/css is capable of SSR. You just need one or two more tweaks.
It's not just a few tweaks. It is very hard to get working properly. However, user that chose to implement your approach can always refer to TSS to setup SSR.
It is also not hard to debug. If you really need to debug, you can do following
Fair enough, it's also the approach implemented in TSS (except that we can optionally add the component name but you could easily add it as well).
If you need additional parameters, just add them to useClasses :) it is a simple function.
Fair enough
Yes it relies on @emotion/css, which relies on stylis, @emotion/serialize, @emotion/cache, @emotion/sheet, etc.
You are right, it isn't a very strong argument.
In our use-case the mui5 migration scripts did the most, the only problem was the makeStyles/useStyles hook, which could be easily solved with this simple 15 lines of code.
There is now a codemod in MUI for migrating from JSS to TSS. See doc
This function can easily be extended to use nested classes or typescript.
Again, with all due respect, no, I don't want people to think. "Well, if I ever need the nested selectors I'll just need to adapt my makeStyles a little bit". Getting selectors to work is a degree of magnitude harder than implementing the base hook.
Again. No hate whatsoever. Just helping people to make an informed decision.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's very nice of you! Much appreciated! :D
This is, infact, extremely hard to adapt this API to work with type inference. I'd say the types definitions represent 90% of the overall effort that went into developing
tss-react.It's not just a few tweaks. It is very hard to get working properly. However, user that chose to implement your approach can always refer to TSS to setup SSR.
Fair enough, it's also the approach implemented in TSS (except that we can optionally add the component name but you could easily add it as well).
Fair enough
You are right, it isn't a very strong argument.
There is now a codemod in MUI for migrating from JSS to TSS. See doc
Again, with all due respect, no, I don't want people to think. "Well, if I ever need the nested selectors I'll just need to adapt my
makeStylesa little bit". Getting selectors to work is a degree of magnitude harder than implementing the base hook.Again. No hate whatsoever. Just helping people to make an informed decision.