You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// inputimport'@twind/macro'constjsx=<buttontw="bg-blue-500"/>// output, as of nowimport{tw}from'twind'constjsx=<buttonclassName={tw`bg-blue-500`}/>// rough proposed output, aliasing to avoid conflictsimport{twas_tw}from'twind'const_macro_tw=(...args)=>_tw(_tw.apply(...args))constjsx=<buttonclassName={_macro_tw`bg-blue-500`}/>
This gives the benefit of reliable styling depending on class name order when using the macro, something that would be especially welcome for users coming from twin.macro and other CSS in JS libs. This should probably also apply to standalone tw usages that are imported from the macro.
At first, I'm thinking this would be an option/flag for the macro, but I'm wondering if there's any reason it shouldn't do this by default 🤔 Would this negatively impact performance? I guess it's hard to know for sure without measurements. cc @sastan
I also realized (right after making the issue 🙃) that the hashed class names would make debugging a little harder. One way to fix that would be to add an extra attribute to the element that shows the actual classes used, so it'll show up in the DOM as <button class="tw-abcxyz" data-tw="bg-blue-500" />
The text was updated successfully, but these errors were encountered:
itsMapleLeaf
changed the title
Output calls wrapped with tw.apply
Output tw.apply calls
Jan 14, 2021
When using the global tw the following should work:
// inputimport'@twind/macro'<buttontw="bg-blue-500"/>// output, as of nowimport{tw}from'twind'<buttonclassName={`${tw.apply`bg-blue-500`}${tw(props.className)}`}/>
This gives the benefit of reliable styling depending on class name order when using the macro, something that would be especially welcome for users coming from twin.macro and other CSS in JS libs. This should probably also apply to standalone tw usages that are imported from the macro.
At first, I'm thinking this would be an option/flag for the macro, but I'm wondering if there's any reason it shouldn't do this by default 🤔 Would this negatively impact performance? I guess it's hard to know for sure without measurements. cc @sastan
Twind is a tailwind in js runtime with to goal to generate tailwind like css. The component mode mirrors the behavior of emotion and styled-components. I see two options:
add a config option which "mode" to use with default to tailwind (need a different naming here as mode is already used by twind setup)
when using the macro we default to the component mode which would all to customize/override the component styles using tailwind class; this is how twind/styled will work
I also realized (right after making the issue 🙃) that the hashed class names would make debugging a little harder. One way to fix that would be to add an extra attribute to the element that shows the actual classes used, so it'll show up in the DOM as <button class="tw-abcxyz" data-tw="bg-blue-500" />
Pending this proposal
Here's the gist:
This gives the benefit of reliable styling depending on class name order when using the macro, something that would be especially welcome for users coming from twin.macro and other CSS in JS libs. This should probably also apply to standalone
tw
usages that are imported from the macro.At first, I'm thinking this would be an option/flag for the macro, but I'm wondering if there's any reason it shouldn't do this by default 🤔 Would this negatively impact performance? I guess it's hard to know for sure without measurements. cc @sastan
I also realized (right after making the issue 🙃) that the hashed class names would make debugging a little harder. One way to fix that would be to add an extra attribute to the element that shows the actual classes used, so it'll show up in the DOM as
<button class="tw-abcxyz" data-tw="bg-blue-500" />
The text was updated successfully, but these errors were encountered: