expose a parseClassList function derived from the existing mergeClassList function

[Rinaldo]

tailwind-merge has to know a lot about tailwind class groups in order to merge classes effectively, but it doesn't expose any of that information. It would be great to have access to a version of the mergeClassList function without the final map and join, one that returns an array of the parsed, filtered objects.

My use-case would be to split tailwind classes by class group. I want to make a custom <input> with a wrapper <div> so I can position an icon 'inside' the input. I'd like to have something like this

const MyInput = props => (
  <div>
    <input {...props} />
  </div>
)

The problem with that is that while most classes like text-sm or bg-white apply to the <input> itself, others like col-span-2 would need to be placed on the wrapper <div>. Instead of exposing a wrapperClass prop on the component, I'd like to place the classes on the appropriate elements automatically to make the wrapper transparent to the consumer. An exposed parseClassList utility from tailwind-merge would allow me to do this.

This would address #357

[dcastil]

Hey @Rinaldo! 👋

I have two different answers to your message. Here are both:

Answer to your feature request

I also thought about it from time to time that it would be useful to expose the low level class info and let people do more custom stuff with it. The challenge lies in how to expose that functionality.

Some boundaries I can think of:

• The API should not introduce breaking changes
• It should reuse the config computed in createTailwindMerge to preserve memory and CPU cycles. Because the config only exists within that function, the API also needs to be exposed from within that function.
• How to make sure that exposing the API won't stall development and usage of tailwind-merge? E.g. when new Tailwind features come out that force me to change the shape of the object passed around in mergeClassList, it would be annoying to most users if I had to bump the major version of tailwind-merge only because of breaking changes in the hypothetical parseClassList function which won't be used by most users.

An initial idea I have is to attach an experimentalRaw property to the twMerge function that would return the objects. Then I'd communicate in the docs that this function could change within any minor version update and ask users to rely on TypeScript to watch out for breaking changes. You could call it like this:

twMerge.experimentalRaw('block', true && 'something-else')

I'm not 100% sure though. 🤔

Answer to your problem

My usual solution to this is a bit dirty but simple: I use an additional outerClassName prop to attach classes to the most outer node in cases where the className prop is attached to an inner node. That also saves you from maintaining a large list of class group IDs that needs to stay in sync with tailwind-merge internals.

[Rinaldo]

Thanks for the detailed response! Everything you said with the experimentalRaw function makes sense to me. I think it's fair to have it exempt from semver if it's documented and has an experimental or unstable prefix. It would be a powerful feature and it would be great if you could add it.

And I currently have something like an outerClassName prop. Splitting the className automatically would make the component more transparent but maybe it would end up being a leaky abstraction.

[dcastil]

Created an issue for this in #385. I'm not too confident about any solution yet, so don't expect anything anytime soon. But I created that issue to have a place to collect all the requests for a lower-level API.