-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added custom classNameMergeFunction configuration to ptOptions #5215
Conversation
This enables the usage of libaries such as tailwind-merge to more sensibly merge classNames together when useing Tailwind.
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 2 Ignored Deployments
|
This looks clever to me. |
Is there any other context that I can add here to move this forward? |
@gucal it would be great if this was included in |
Thank you for your effort. Thanks! |
This is exactly what would unblock us from moving to version 10 and also utilise unstyled mode with tailwind. Is there any update on the timeline for this? Unfortunate that the release for the css variables were pushed a long with this bottleneck for Tailwind and unstyled mode. We will unwillingly have to stick with scss themes in our remake |
@bweis any chance you could update the conflicts? If not I understand since its been a long time to merge this PR but I think I am ready to merge it for 10.4.0 it fixes so many TailWind issues |
Implemented with: #5755 |
This is the next iteration on #5209
Fix #5144
Fix #5564
Fix #5570
New Context
Some CSS Class systems require a careful merging of classnames since there is no way to know what classnames have higher priority. This new configuration option will allow consumers of the library to assume the responsibility for merging these classnames. (ie: tailwind-merge for Tailwind)
After discussing in the discord, we determined this composable solution would be a better choice as to not constrain ourselves to tailwind support.
Problem that this is solving
This is an issue in broader CSS. But when consuming a component lib its not of large impact generally because you would have the component lib's CSS defined before your local, so your local CSS would take priority. However, when using tailwind this is not the case and is well documented by tailwind itself. Because of this many tailwind users rely on tailwind merge to resolve these conflicts.
Copying the preset and customizing it to your own liking is an partial option, however this does not solve the use case in which you either use the tailwind preset or your own and then later in your application want to customize a component using the pt={} props. This will never work with tailwind classes.
If a user uses the Tailwind preset or a custom PT config at the provider. But then wants to override a class of a specific component, this will not be possible for them to do with the existing APIs.
This change aims to fix that and is necessary for proper tailwind (or other css library) support.
As it stands before this PR, the paginator's bg color can never be reliably changed:
With the proposed non-breaking changes in this PR you will be able to properly use talwind css in primereact. Without it tailwind support is not reliable for anyone that wants to modify any styling in components themselves beyond the provider passthrough.
Notable changes
mergeProps
function is now consumed via a hookuseMergeProps
so that context can be provided automatically.mergeProps
function has been made "package private" as to only be used by theComponentBase.js
.Remaining questions/notes
usePassthrough
"hook" is a misnomer and should really be renamed asmergePassthrough
since it is not a hook in a traditional sense, more-so a utility function.Previous PR Context