@adamwathan I'm currently struggling with integrating TailwindUI (team license, yey!) into an existing React app due to this composability issue. I've taken a stab at a merge function here: https://github.com/mariusmarais/tailwind-cascade

I've managed to figure out grouping, and out-of-group overrides, but would appreciate some advice on consuming the Tailwind config. A pointer or two on where to start should be enough.

Thanks

Its quite easy to get the config by using the
const resolveConfig = require("tailwindcss/resolveConfig");

so you can then code it like this for ex.

const resolveConfig = require("tailwindcss/resolveConfig"); const customConfig = require("src/tailwind.config"); const config = resolveConfig(customConfig);

And there it is the whole config in json with all custom added props.

Hello @adamwathan! it seems like @dcastil was able to solve this problem with https://github.com/dcastil/tailwind-merge 🙂

// last conflicting class wins
twMerge('p-5 p-2 p-4') // → 'p-4'

// resolves non-trivial conflicts
twMerge('inset-x-px -inset-1') // → '-inset-1'
twMerge('bottom-auto inset-y-6') // → 'inset-y-6'
twMerge('inline block') // → 'block'

// supports arbitrary properties
twMerge('bg-black bg-[color:var(--mystery-var)]') // → 'bg-[color:var(--mystery-var)]'
twMerge('grid-cols-[1fr,auto] grid-cols-2') // → 'grid-cols-2'

Have you taken a look at this yet? Community response seems largely positive, and enough people seem to be in agreement that this is a feature tailwind could largely benefit from for JS SPAs for a while now.

• https://twitter.com/tannerlinsley/status/1550475765468213248 (TanStack creator/maintainer)
• https://dev.to/diogoko/overriding-tailwind-classes-in-react-4po3

Do you know if there's a chance we could see this sort of functionality merged into the official Tailwind package? ❤️ Or something similar that addresses this?

I haven't played with it myself because I've never had this problem, but it seems to work great for the people who need it 👍 I would just recommend using this package if it solves a problem you have, no real reason it needs to be first-party.

Personally I've always treated this problem as a sign that the component has opinions baked into it that should be external, or that there is a subcomponent to extract that can have less opinions. It's definitely possible I just haven't run into a super compelling motivating problem though.

I wrote one of the earlier helpers in this thread but I never use it anymore, @adamwathan is completely right. Once you get a better handle on writing good public APIs for your components that map options to your design system well you don't need it. I tend to provide className as an escape hatch and if someone really wants to force a component beyond what it's meant to do they can use the ! modifier.

You could setup some matching functions in precedence order... First hit assigns grouping, last item per group wins.

I use a prefix, so it's getting a little complicated, but you could then pass unrelated classes through there as well, which would be typical in a React className extension:

import { ClassValue } from 'classnames/types';
import classNames from 'classnames';
import { groupBy, partition } from 'lodash';

function createTailwindDedup({ prefix }: { prefix?: string } = {}) {
  const RULES: Array<(name: string) => false | string> = [
    n => [/^text-[^-]+-\d\d\d$/, /^text-white$/].some(r => r.test(n)) && 'text-color',
    n => /^text-\d+$/.test(n) && 'text-size',
    n => n.replace(/^(.*)-[^-]*$/, '$1') // standard tailwind
  ];

  return function twcx(...args: ClassValue[]) {
    const classes = classNames(...args).split(' ');

    const [checkClasses, skipClasses] = prefix ? partition(classes, c => c.startsWith(prefix)) : [classes, []];

    const groups = groupBy(prefix ? checkClasses.map(n => n.replace(prefix!, '')) : checkClasses, n => {
      for (const r of RULES) {
        const v = r(n);
        if (v) {
          return v;
        }
      }
      return n;
    });

    return skipClasses.concat(Object.values(groups).map(g => (prefix ? prefix : '') + g[g.length - 1])).join(' ');
  };
}

[
  [{ prefix: 'tw-' }, 'tw-text-18 tw-text-14 tw-p-0'],
  [{}, 'p-0', { 'p-1': true }],
  [{ prefix: 'tw-' }, 'tw-text-white', 'tw-text-red-400']
].forEach(([config, ...args]) => {
  const twcx = createTailwindDedup(config as any);

  console.log(config, ':\n', args, '=>', twcx(...args), '\n\n');
});

Result:

{ prefix: 'tw-' } :
 [ 'tw-text-18 tw-text-14 tw-p-0' ] => tw-text-14 tw-p-0 


{} :
 [ 'p-0', { 'p-1': true } ] => p-1 


{ prefix: 'tw-' } :
 [ 'tw-text-white', 'tw-text-red-400' ] => tw-text-red-400

This is getting pretty close to a package and obviously would need many tests :)

RULES NOT COMPLETE - DO NOT USE

I think that could work, but would we'd need to define all the rules.

Please tell me someone already built this

Been looking at this some more this morning... Found https://github.com/muhammadsammy/tailwindcss-classnames who has classnames => plugin mapped out, but using just that would lump all margins together, all paddings together, etc., instead of per direction.

Someone could map everything by hand, but ideally TailwindCSS could generate a list of classes and their grouping at build time, maybe into a separate file? It would then be quite simple to load that and handle 'last write wins'.

{
"m-0": "margin",
"m-1": "margin",
"m-x-1": "margin-x",
"-m-x-1": "margin-x",
...
"uppercase": "typography-casing",
"lowercase": "typography-casing"
}

It feels like that info should be available inside the build system somewhere? Or maybe the ruleset isn't as complicated as I think it is, and my approach above could work?

Nice idea, the metadata generated should also include all the variants for each group so they will not conflict. You could also generate metadata for media queries so they can be used for removing elements from the code and not hiding elements with CSS. If atomic CSS is not used problems could occur but that the responsibility of the plugin maker, but either way I would write my own plugins so it is not a big problem for me. The best thing about your approach is that would not require breaking changes, do you think we should notify Adam and the other people working/maintaing the library.

Yes, I would love it if someone with more insight into the codebase could weigh in. I don't really like summoning people to discussions, but where goes... @adamwathan could you please take a look or delegate? 😄

A concrete example is here https://github.com/mariusmarais/tailwind-cascade and it goes deeper into the mechanism in the readme.

How feasible is it for Tailwind to generate the override from config?

That's quite clever, but you would still have only one override level :-/

worked for me! thanks a lot!

Again, pure genius :)

But I think we're seeing that overriding is something that would be useful in core, since so many people are coming up with novel ways of achieving it, but all with fundamental limitations.

I'm starting on a new project now and I'm giving the CSS-in-JS thing a try with twin.macro and emotion. I don't really like it that much (too much magic), but it has solved every single scenario I can think of.

I'd argue the opposite. If we have class-level overriding, then you can override by just using the classes from Tailwind. If you don't, you end up with these monstrosities where props are used to dynamically build classes or styles. (That's what your example actually shows, using props to build classes.)

The whole point is to not do that.

In my usage (React), we have a standard <MyButton/> that applies our general brand guidelines. But when you put three of them next to each other, and you want to go from [==] [==] [==] to [=|=|=] you can't by just adding classnames. So you end up with silly props to apply classes only in certain cases.

Whereas, if you can override simply with classnames, it's as easy as:

<div>
  <MyButton className="w-24 rounded-r-none">Left</MyButton>
  <MyButton className="w-24 rounded-none">Middle</MyButton>
  <MyButton className="w-24 rounded-l-none">Right</MyButton>
</div>

// on top of a 
const MyButton = ({className, children, ...other}) => {
  return <button className={
    magicMethod("text-sm w-32 border border-gray-300 rounded-md cursor-default", className)
  } ...other>
    {children}
  </button>;
};

(Note that there are no additional props to what a button takes.)

That ^^ doesn't work right now because of the definition order of the CSS width & rounded classes. An especially nice foot-gun is that w-48 will work but w-24 won't. It does work through my mapping util (magicMethod), but that needs to be updated by hand and kept in sync with TW versions, config, etc.

You are essentially advocating to split this example into two (with additional prop direction=L/R/M) or four (for L/R/M each) base components, which cannot share common branding classes, or to go back to slightly better custom CSS with @apply.

So, to clarify, the idea is build LESS, SIMPLER base components that allow overriding, not complex components that have branching logic and gotchas.

Do you really think multiple components is a better choice, or have you simply accepted it as the only option?

(Sorry for more text...)

The above is possible using some of the workarounds mentioned in this thread, but the following isn't: a "ribbon button" component, because overriding that would require an entirely new additional overridable layer or duplication. For example:

const RibbonButton = ({className, position, children, ...other}) => {
  const borderTypes = { left: 'rounded-r-none', middle: 'rounded-none', right: 'rounded-l-none' };
  return <MyButton
    className={magicMethod(borderTypes[position], 'w-24', className)}
    ...other
    >
    {children}
    </MyButton>;
}

Overriding that ^ again to add more stuff might be difficult, depending on where you used what, meaning the component-authoring process becomes whack-a-mole with Tailwind.

(These examples might seem trivial and convoluted at the same time, but in a large app the component hierarchy can become immense -- either vertical with inheritance or horizontal with mixins / @apply / manual copy & paste. If components can be stupid-simple, but still override-able, things are much more manageable, especially when working with branding guidelines.

Think of adding standardised disabled state to that base button, or "canHover" apply standard overridable classes, or so-on.)

Tailwinds UI has a separate React button component for the following:

• Button with leading icon
• Button with trailing icon
• Primary Button
• Secondary Button
• White Button
• Round Button

It's certainly not un-idiomatic to repeat components.

While I can't speak for the creators; I think Tailwinds favors comprehension over configuration, that it's better to have multiple inflexible components with understandable markup than to have a single flexible component that offers little hint of what it actually looks like on browser.

I think your example case though is pretty easily expressed without worrying about override precedence. When I do need "overrides", I feel it's better expressed by not having the "base class" defined in the base component at all- instead insisting that all uses of the component provide for this. It's simple when they're all part of the same file

<div>
  <LeftButton>Left</LeftButton>
  <MiddleButton>Middle</MiddleButton>
  <RightButton>Right</RightButton>
</div>

/* Buttons.tsx */
export const DefaultButton = button("w-32 rounded-md)
export const LeftButton = button("w-24 rounded-l")
export const MiddleButton = button("w-24")
export const RightButton = button("w-24 rounded-r")

const button = (className) => (function Button ({children, ...other}) {
  return <button ...other className={clsx("text-sm border border-gray-300 cursor-default", className)}>
    {children}
  </button>;
})

I commonly see people resorting to stuff like this in tailwinds where I can't even glean what the component looks like slightly just by glancing over the body of render as I should be able to do:

  return <button 
    className={clsx(
      props.buttonType === buttonClass, props.className)}
  >
    {props.LeftIcon ? <span className={clsx(leftIconContainerClass, props.leftIconContainerClassName)}><Props.LeftIcon>
    {label}
   { props.rightIcon ? .... etc

and my feeling is adding this to core would further encourage this approach

I agree that specialised components make sense, but I disagree that it's preferred to have duplicating styles once you do that. I would like to have base styling handled at the base level. Maybe one higher than the actual logic component like headlessui, but certainly not every time you use it.

I also agree that your last example is a mess, I'm also trying to do away with that kind of thing in base-level components.

But it feels like only half of the maintainability question is answered. What about rebranding? Refreshing all UI because your callcenter upgraded to 1080p screens? Your field agents switching to a ruggedised device with and odd screen?

If every project is clean slate build & ship, then that approach works, but working on a constantly expanding core business operations project you need better answers for long-term maintainability. Maybe TW isn't really aimed at that segment, but it could be, or at least not make it worse.

On the other hand, Tailwind CSS intellisense has a similar function, for example if you type in two classes that will override each other in the className it will give you a warning.

So there is an existing logic for that inside that plugin repo

I thinks its
https://github.com/tailwindlabs/tailwindcss-intellisense/blob/master/packages/tailwindcss-language-service/src/diagnostics/getCssConflictDiagnostics.ts

I will try to understand the logic behind it :) But its not quite so simple, maybe somebody will figure it out :)

@adamwathan - with my blade components I have a panel for example which is used like:

<x-panel>
<h2>Some title</h2>
<p>Some paragraph</p>
</x-panel>

Which has a default space-y-md class. But sometimes, we want to have space-y-lg. So for me the trade off of requiring everytime to write this:

<x-panel class="space-y-md">
<h2>Some title</h2>
<p>Some paragraph</p>
</x-panel>

Is worth it, otherwise I am expecting a backend dev using these components to have to always remember how to add the space between and what space it should be.

For tweaks like that consider just defining a prop.

<x-panel spacing="lg">

...where the default is medium.

Yeh I was going down that route initially, but then I was coming across times where maybe that prop needs to be used on multiple components. And I was defining logic to add the classes on each individual component as well.

This was abstracted using traits, but then if you have just a simple component you need still create an additional PHP class, consume the properties in the PHP class and include the trait.

I ended up coming to a logical conclusion to have something like <x-panel override-space-x="lg"> That could be a generic attribute that is applied to all components, override-tailwind-class-name="overridewith". But I felt that could also get complicated as well.

Thank you for this! I tried hard searching for my issue and found this solution!

Won't use of the JIT feature really inflate our production bundle size, since tailwind would no longer be a dev dependency? Especially if we use additional tailwind extensions such as tailwind-typography?

Cool solution :)

👍👍👍 That's brilliant.

This does not work for buttons, as the base style reset has a higher specificity see your example

@AaronBeaudoin Hi. I'm interested in this approach, but I failed to see how it could help to resolve this issue. Could you explain more?

This is great! Glad someone cracked that nut! Looks like this is going to make my "override" plugin obsolete, which is a good thing!