Awesome thanks for writing this up! I've been thinking of this exact setup having tried both routes separately.
The problem I had was the tailwind macro on its own some selectors were not working. So I ended up just going the standalone tailwindcss route and found this.
Some questions I had -
1-
Will this double setup not lead to a large CSS payload. You've basically got every tailwind selector twice. Once via @tailwind utilities and then a second time when you're using tailwind macro via tw`` is this not an issue?
2-
In the AppStyles example className is mixed with ${tw}, why not just use ${tw` entirely? From my understanding this would allow you to not require the @tailwind utilities import ( providing you do not have the same issue as me where some classes do not work )
3 -
When I was looking @ the tailwind macro code it looks like all the tailwind > CSS mappings are hand crafted in there in order to translate. I had worried this can fall out of date ( and I believe already is ) easily without some love have you noticed this?
Thanks for taking the time to read the crazy contraption I have put together.
tw does not have access to the entirety of Tailwinds classes like pseudo selectors and many others.
The styled-component attr function has access to all of Tailwinds classes. With Babel macro config file we’re updating the macro on where to find Tailwind.
The idea is to use the attrs function as a parent container where all of Tailwinds classes are available and tw as secondary nested using the most common of Tailwinds selectors.
Also with the Styled Components function you have the ability to provide standard CSS for things that Tailwind does not have in its codebase.
I have another article that I am writing to handle Tailwind compression using @fullhuman/purgecss
As far as I know the tw macro only creates classes to access macro version of Tailwind classes but only relies on the single Tailwind import and does not duplicate.
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.
Awesome thanks for writing this up! I've been thinking of this exact setup having tried both routes separately.
The problem I had was the tailwind macro on its own some selectors were not working. So I ended up just going the standalone tailwindcss route and found this.
Some questions I had -
1-
Will this double setup not lead to a large CSS payload. You've basically got every tailwind selector twice. Once via @tailwind utilities and then a second time when you're using tailwind macro via tw`` is this not an issue?
2-
In the AppStyles example className is mixed with ${tw}, why not just use ${tw` entirely? From my understanding this would allow you to not require the @tailwind utilities import ( providing you do not have the same issue as me where some classes do not work )
3 -
When I was looking @ the tailwind macro code it looks like all the tailwind > CSS mappings are hand crafted in there in order to translate. I had worried this can fall out of date ( and I believe already is ) easily without some love have you noticed this?
Hi Tom!
Thanks for taking the time to read the crazy contraption I have put together.
tw does not have access to the entirety of Tailwinds classes like pseudo selectors and many others.
The styled-component attr function has access to all of Tailwinds classes. With Babel macro config file we’re updating the macro on where to find Tailwind.
The idea is to use the attrs function as a parent container where all of Tailwinds classes are available and tw as secondary nested using the most common of Tailwinds selectors.
Also with the Styled Components function you have the ability to provide standard CSS for things that Tailwind does not have in its codebase.
I have another article that I am writing to handle Tailwind compression using @fullhuman/purgecss
As far as I know the tw macro only creates classes to access macro version of Tailwind classes but only relies on the single Tailwind import and does not duplicate.