Util classname 1 #616
Util classname 1 #616
Conversation
|
Warning Rate limit exceeded@GoldGroove06 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 15 minutes and 11 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (2)
WalkthroughThe pull request introduces a new dependency, Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Outside diff range and nitpick comments (11)
src/components/ui/Code/Code.tsx (1)
3-3: Consider simplifying static className handlingSince you're using a static string
'rui-code-root'without any conditional logic, usingclsxhere adds unnecessary overhead. You could either:
- Keep the direct string assignment if no className customization is needed
- Add className prop support for external customization (recommended)
export type CodeProps = { children: React.ReactNode; + className?: string; } -const Code = ({ children }: CodeProps) => { - return <code className={clsx('rui-code-root')}> +const Code = ({ children, className }: CodeProps) => { + return <code className={clsx('rui-code-root', className)}>Also applies to: 9-9
src/components/ui/Accordion/fragments/AccordionHeader.tsx (1)
2-2: Consider adding a base className for consistent stylingThe component currently only passes through the provided className. Consider adding a base class (e.g., 'rui-accordion-header') to maintain consistent styling across implementations:
- <div className={clsx(className)}> + <div className={clsx('rui-accordion-header', className)}>Also applies to: 11-11
src/components/ui/AlertDialog/fragments/AlertDialogOverlay.tsx (1)
11-11: Consider simplifying the clsx usageSince you're only passing a single template literal, the
clsxwrapper might be unnecessary here. However, if you plan to add more conditional classes in the future, the current implementation provides a good foundation.You could simplify it to:
- className={clsx(`${rootClass}-overlay`)} onClick={handleOverlayClick}> + className={`${rootClass}-overlay`} onClick={handleOverlayClick}>Or if you prefer consistency with other components using
clsx:- className={clsx(`${rootClass}-overlay`)} onClick={handleOverlayClick}> + className={clsx(rootClass + '-overlay')} onClick={handleOverlayClick}>src/components/ui/AlertDialog/fragments/AlertDialogContent.tsx (1)
14-14: Consider simplifying the clsx usageSimilar to AlertDialogOverlay, since you're only passing a single template literal, the
clsxwrapper might be unnecessary. However, maintaining consistency across components might be more valuable than the minor optimization.You could simplify it to:
- <div className={clsx(`${rootClass}-content`)}> + <div className={`${rootClass}-content`}>Or if you prefer consistency with other components using
clsx:- <div className={clsx(`${rootClass}-content`)}> + <div className={clsx(rootClass + '-content')}>src/components/ui/BlockQuote/BlockQuote.tsx (1)
Line range hint
11-11: Fix incorrect props type definition.The props type is incorrectly defined as an array
Record<string, any>[]but is used as a single object with the spread operator.Apply this fix:
- props: Record<string, any>[] + props?: Record<string, any>src/components/ui/Callout/Callout.tsx (1)
2-2: LGTM with suggestions for improvement.While the clsx implementation is correct, there are two improvements to consider:
- The props type should be a single object, not an array
- The
color ?? undefinedis redundant as undefined is the default for optional propsApply these improvements:
- props?: object[] + props?: Record<string, any>- return (<CalloutRoot customRootClass={customRootClass} className={clsx(className)} color={color ?? undefined} {...props}> + return (<CalloutRoot customRootClass={customRootClass} className={clsx(className)} color={color} {...props}> {children} </CalloutRoot>);Also applies to: 18-20
src/components/ui/Callout/fragments/CalloutRoot.tsx (1)
3-3: LGTM! Verify className prop typeThe implementation of
clsxis correct and maintains existing functionality. However, consider removing the empty string union type fromclassName?: string | ''asclsxalready handles empty strings gracefully.- className?: string | '' ; + className?: string;Also applies to: 16-16
src/components/ui/Badge/fragments/BadgeRoot.tsx (1)
1-1: Consider standardizing clsx usage patternsWhile the implementation is generally good, I noticed some inconsistencies in how
clsxis being used across components. Consider:
- Standardizing when to use
clsx(e.g., only when combining multiple classes)- Adding unit tests specifically for className handling
- Creating a shared utility function for common className patterns
Also, please investigate the failing tests mentioned in the PR description, even though they're reportedly unrelated to these changes.
src/components/ui/Avatar/Avatar.tsx (1)
2-2: Simplify unnecessary clsx usageUsing clsx with a single className argument provides no additional benefit and adds unnecessary complexity.
Consider simplifying the code:
-import { clsx } from 'clsx'; // ... -className={clsx(className)} +className={className}Also applies to: 23-23
src/components/ui/AlertDialog/fragments/AlertDialogRoot.tsx (1)
4-4: Consider simplifying the className handlingThe current implementation uses both
customClassSwitcherandclsx, butclsxwith a single argument doesn't provide any additional benefit. Consider either:
- Using only
customClassSwitcherif no conditional classes are needed- Combining both custom and conditional classes using
clsxin one place- const rootClass = customClassSwitcher(customRootClass, COMPONENT_NAME); - <div className={clsx(rootClass)} > + <div className={clsx(customClassSwitcher(customRootClass, COMPONENT_NAME))} >Also applies to: 34-34
package.json (1)
Line range hint
1-1: Overall Implementation ReviewThe implementation of clsx for className management is clean and consistent across components, with one exception in AccordionRoot.tsx that needs fixing. Please:
- Fix the syntax error in AccordionRoot.tsx
- Consider adding tests specifically for className combinations to ensure the clsx implementation works as expected
For future maintenance:
- Consider creating a custom hook or utility function to standardize className composition across components
- Document the className composition patterns in the component documentation
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (21)
package.json(1 hunks)src/components/ui/Accordion/fragments/AccordionContent.tsx(2 hunks)src/components/ui/Accordion/fragments/AccordionHeader.tsx(2 hunks)src/components/ui/Accordion/fragments/AccordionItem.tsx(2 hunks)src/components/ui/Accordion/fragments/AccordionRoot.tsx(2 hunks)src/components/ui/Accordion/fragments/AccordionTrigger.tsx(2 hunks)src/components/ui/AlertDialog/fragments/AlertDialogContent.tsx(2 hunks)src/components/ui/AlertDialog/fragments/AlertDialogOverlay.tsx(1 hunks)src/components/ui/AlertDialog/fragments/AlertDialogRoot.tsx(2 hunks)src/components/ui/Avatar/Avatar.tsx(2 hunks)src/components/ui/AvatarGroup/AvatarGroup.tsx(2 hunks)src/components/ui/AvatarGroup/fragments/AvatarGroupRoot.tsx(2 hunks)src/components/ui/Badge/Badge.tsx(2 hunks)src/components/ui/Badge/fragments/BadgeRoot.tsx(2 hunks)src/components/ui/BlockQuote/BlockQuote.tsx(2 hunks)src/components/ui/Button/Button.tsx(2 hunks)src/components/ui/Callout/Callout.tsx(2 hunks)src/components/ui/Callout/fragments/CalloutRoot.tsx(2 hunks)src/components/ui/Card/Card.tsx(1 hunks)src/components/ui/Card/fragments/CardRoot.tsx(2 hunks)src/components/ui/Code/Code.tsx(1 hunks)
🧰 Additional context used
🪛 Biome (1.9.4)
src/components/ui/Accordion/fragments/AccordionRoot.tsx
[error] 58-58: expected , but instead found {
Remove {
(parse)
🪛 eslint
src/components/ui/Button/Button.tsx
[error] 24-24: Unexpected template string expression.
(no-template-curly-in-string)
🔇 Additional comments (11)
src/components/ui/AvatarGroup/fragments/AvatarGroupRoot.tsx (2)
2-2: LGTM: Clean import of clsx utility
The import is correctly placed and follows the existing import structure.
14-14: LGTM: Proper implementation of clsx
The clsx implementation correctly handles both the rootClass and optional className prop, maintaining the same functionality while providing better handling of undefined values.
src/components/ui/AlertDialog/fragments/AlertDialogOverlay.tsx (1)
4-4: LGTM: Clean import of clsx utility
The import is correctly placed and follows the existing import structure.
src/components/ui/AlertDialog/fragments/AlertDialogContent.tsx (1)
3-3: LGTM: Clean import of clsx utility
The import is correctly placed and follows the existing import structure.
src/components/ui/Card/fragments/CardRoot.tsx (1)
3-3: LGTM! Verify className behavior with undefined values.
The implementation correctly uses clsx for className management. The change from template literals to clsx is appropriate and matches the PR objectives.
Let's verify that undefined className values are handled correctly:
Also applies to: 16-16
✅ Verification successful
Let me analyze the className handling implementation and test coverage.
Implementation handles undefined className values correctly
The implementation is safe and properly handles undefined values:
- Default value
className = ''in the props destructuring ensures className is always a string clsxlibrary safely handles undefined/null values by design- Test coverage confirms className functionality works as expected
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for test cases involving undefined className values
rg -l "className={undefined}" || rg -l "className: undefined"
Length of output: 177
Script:
#!/bin/bash
# Search for test files related to Card components and check className handling
fd "Card.*test" --exec cat {}
# Search for className usage in Card components
ast-grep --pattern 'className={$_}'
Length of output: 1267
Script:
#!/bin/bash
# Check the actual implementation of className handling in CardRoot
cat src/components/ui/Card/fragments/CardRoot.tsx
Length of output: 684
src/components/ui/BlockQuote/BlockQuote.tsx (1)
3-3: LGTM! className handling is correctly updated.
The implementation correctly uses clsx for className management, consistent with other components.
Also applies to: 17-17
src/components/ui/Badge/fragments/BadgeRoot.tsx (1)
3-3: LGTM! Consistent implementation
The implementation of clsx is correct and consistent with the pattern used in other components. The change maintains existing functionality while improving className handling.
Also applies to: 18-18
src/components/ui/Accordion/fragments/AccordionContent.tsx (1)
4-4: LGTM! Clean implementation of clsx
The changes correctly implement the clsx utility for className management, maintaining the existing functionality while improving class name handling.
Also applies to: 20-20
src/components/ui/AvatarGroup/AvatarGroup.tsx (1)
2-2: LGTM! Clean implementation of clsx
The implementation correctly uses clsx to handle the className prop, allowing for flexible class name combinations while maintaining readability.
Also applies to: 21-21
src/components/ui/Accordion/fragments/AccordionItem.tsx (1)
64-64: LGTM! Clean implementation of clsx
The className implementation correctly combines the base class with the optional className prop using clsx.
package.json (1)
132-132: LGTM! Verify version compatibility
The addition of clsx as a runtime dependency is correct. Version ^2.1.1 is the latest stable version.
Run the following script to verify version compatibility:
✅ Verification successful
LGTM! No compatibility issues found
The verification shows that clsx is being used correctly throughout the UI components for className composition. All usages follow the standard pattern and there are no type errors or compatibility issues detected. The package is properly integrated into the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for version compatibility issues with clsx
# Check if clsx is used in any test files
rg -l "from 'clsx'" -g "*.test.*"
# Check if there are any type errors in files using clsx
rg -l "from 'clsx'" | xargs dirname | sort -u | while read dir; do
find "$dir" -name "*.d.ts" -o -name "*.ts" -o -name "*.tsx" | while read file; do
echo "Checking $file for type errors..."
grep -H "className.*clsx" "$file" || true
done
done
Length of output: 13064
| export type CardProps = { | ||
| customRootClass?: string; | ||
| className?: string; | ||
| props?: any; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Avoid using 'any' type and consider consolidating className props
- The
props?: anytype is not recommended as it bypasses TypeScript's type checking. Consider using a more specific type or removing it if not needed. - Having both
classNameandcustomRootClassprops seems redundant. Consider consolidating them into a singleclassNameprop.
export type CardProps = {
- customRootClass?: string;
className?: string;
- props?: any;
+ props?: React.ComponentProps<'div'>;
} & React.ComponentProps<'div'>;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export type CardProps = { | |
| customRootClass?: string; | |
| className?: string; | |
| props?: any; | |
| export type CardProps = { | |
| className?: string; | |
| props?: React.ComponentProps<'div'>; | |
| } & React.ComponentProps<'div'>; |
| const Card = ({ children, className = '', customRootClass, ...props }: PropsWithChildren<CardProps>) => ( | ||
| <CardRoot className={className} customRootClass={customRootClass} {...props}> | ||
| <CardRoot className={clsx(className)} customRootClass={customRootClass} {...props}> | ||
| {children} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Simplify props handling by removing customRootClass
After consolidating the className props, update the component implementation:
-const Card = ({ children, className = '', customRootClass, ...props }: PropsWithChildren<CardProps>) => (
- <CardRoot className={clsx(className)} customRootClass={customRootClass} {...props}>
+const Card = ({ children, className = '', ...props }: PropsWithChildren<CardProps>) => (
+ <CardRoot className={clsx('rui-card', className)} {...props}>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const Card = ({ children, className = '', customRootClass, ...props }: PropsWithChildren<CardProps>) => ( | |
| <CardRoot className={className} customRootClass={customRootClass} {...props}> | |
| <CardRoot className={clsx(className)} customRootClass={customRootClass} {...props}> | |
| {children} | |
| const Card = ({ children, className = '', ...props }: PropsWithChildren<CardProps>) => ( | |
| <CardRoot className={clsx('rui-card', className)} {...props}> | |
| {children} |
| @@ -1,14 +1,14 @@ | |||
| import React, { PropsWithChildren } from 'react'; | |||
There was a problem hiding this comment.
💡 Codebase verification
Based on the shell script results, I can now generate the final response:
Inconsistent className handling patterns detected
The codebase shows mixed patterns for handling classNames:
- Some components use
clsxutility:Code.tsx,Badge.tsx,Button.tsx - Others use template literals:
ToggleGroupRoot.tsx,TextArea.tsx,Strong.tsx - Base class naming is also inconsistent:
- Most components use custom root classes without 'rui-' prefix
- Only
Code.tsxuses the 'rui-' prefix pattern
🔗 Analysis chain
Verify consistent className handling across components
Let's verify that all UI components follow the same pattern for className handling.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for consistent className handling patterns across UI components
# Find all UI component files
echo "Checking className handling patterns..."
rg -l "className=" src/components/ui/ | while read -r file; do
echo "\nFile: $file"
# Show className related code with context
rg -A 2 -B 2 "className=" "$file"
done
# Verify base class naming convention
echo "\nChecking base class naming convention..."
rg "className=.*['\"]rui-" src/components/ui/
Length of output: 46635
| @@ -1,5 +1,5 @@ | |||
| import React from 'react'; | |||
There was a problem hiding this comment.
💡 Codebase verification
Props typing issues confirmed in multiple components
The following components have incorrect props typing where props is defined as an array Record<string, any>[] instead of a spread parameter type:
src/components/ui/Link/Link.tsxsrc/components/ui/Em/Em.tsxsrc/components/ui/Kbd/Kbd.tsxsrc/components/ui/BlockQuote/BlockQuote.tsx
These components use rest parameters (...props) which should be typed as a record object, not an array. The correct type should be Record<string, any> without the array notation.
🔗 Analysis chain
Verify props typing across all components.
Similar props typing issues were found in multiple components. It would be beneficial to verify and fix this pattern across the entire codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for potentially incorrect props type definitions
rg "props:.*\[\]" "src/components/"
Length of output: 303
Script:
#!/bin/bash
# Let's check the actual component props definitions in these files
echo "=== Link.tsx ==="
ast-grep --pattern 'interface $_ {
$$$
}' src/components/ui/Link/Link.tsx
echo -e "\n=== Em.tsx ==="
ast-grep --pattern 'interface $_ {
$$$
}' src/components/ui/Em/Em.tsx
echo -e "\n=== Kbd.tsx ==="
ast-grep --pattern 'interface $_ {
$$$
}' src/components/ui/Kbd/Kbd.tsx
echo -e "\n=== BlockQuote.tsx ==="
ast-grep --pattern 'interface $_ {
$$$
}' src/components/ui/BlockQuote/BlockQuote.tsx
Length of output: 513
Script:
#!/bin/bash
# Let's check the component definitions directly
echo "=== Link.tsx ==="
rg -A 10 "type.*Props.*=|interface.*Props" src/components/ui/Link/Link.tsx
echo -e "\n=== Em.tsx ==="
rg -A 10 "type.*Props.*=|interface.*Props" src/components/ui/Em/Em.tsx
echo -e "\n=== Kbd.tsx ==="
rg -A 10 "type.*Props.*=|interface.*Props" src/components/ui/Kbd/Kbd.tsx
echo -e "\n=== BlockQuote.tsx ==="
rg -A 10 "type.*Props.*=|interface.*Props" src/components/ui/BlockQuote/BlockQuote.tsx
Length of output: 2031
| @@ -2,6 +2,7 @@ | |||
| import React from 'react'; | |||
| import BadgeRoot from './fragments/BadgeRoot'; | |||
| import BadgeContent from './fragments/BadgeContent'; | |||
| import { clsx } from 'clsx'; | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Simplify unnecessary clsx usage
The current usage of clsx with a single argument is redundant since there's no class name concatenation or conditional logic. You can pass the className directly.
- return <BadgeRoot customRootClass={customRootClass} className={clsx(className)} color={color ?? undefined} {...props}>
+ return <BadgeRoot customRootClass={customRootClass} className={className} color={color ?? undefined} {...props}>Also applies to: 15-15
| @@ -1,6 +1,7 @@ | |||
| import React, { useContext } from 'react'; | |||
| import { AccordionContext } from '../contexts/AccordionContext'; | |||
| import { AccordionItemContext } from '../contexts/AccordionItemContext'; | |||
| import { clsx } from 'clsx'; | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Optimize clsx usage by removing template literal
The current implementation uses a template literal within clsx, but clsx can handle multiple arguments directly for better readability and performance.
- className={clsx(`${rootClass}-trigger`, className)}
+ className={clsx(rootClass + '-trigger', className)}Or even better, if you want to maintain consistency across the codebase:
- className={clsx(`${rootClass}-trigger`, className)}
+ className={clsx([rootClass + '-trigger', className])}Also applies to: 35-35
💡 Codebase verification
Template literals in clsx calls need to be replaced with string concatenation
The verification revealed inconsistent className handling patterns across the codebase:
- Several components are using template literals within clsx calls (e.g.,
clsx(`${rootClass}-trigger`)), which is unnecessary since clsx already handles string concatenation - The pattern appears in multiple files:
- src/components/ui/AlertDialog/fragments/AlertDialogContent.tsx
- src/components/ui/Accordion/fragments/AccordionTrigger.tsx
- src/components/ui/Accordion/fragments/AccordionItem.tsx
- src/components/ui/AlertDialog/fragments/AlertDialogOverlay.tsx
- src/components/ui/Accordion/fragments/AccordionContent.tsx
These should be simplified to clsx(rootClass + '-trigger') or better yet, use string concatenation without template literals: clsx(rootClass + '-trigger', className).
🔗 Analysis chain
Verify consistent className handling patterns
Let's check for consistency in className handling across the codebase.
Also applies to: 35-35
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for different className handling patterns
# Check for template literals within clsx calls
echo "Checking for template literals within clsx..."
rg "clsx\(`\${.*?}`" --type typescript
# Check for direct string concatenation in className
echo "Checking for string concatenation in className..."
rg "className=.*?\+.*?" --type typescript
# Check for potential mixing of different className utilities
echo "Checking for mixed usage of className utilities..."
rg "(clsx|classnames|cn)\(" --type typescript
Length of output: 645
Script:
#!/bin/bash
# Description: Check for different className handling patterns with correct file types
# Check for template literals within clsx calls
echo "Checking for template literals within clsx..."
rg "clsx\(`.*?\$" -t tsx -t jsx -t ts -t js
# Check for direct string concatenation in className
echo "Checking for string concatenation in className..."
rg "className=.*?\+" -t tsx -t jsx -t ts -t js
# Check for potential mixing of different className utilities
echo "Checking for mixed usage of className utilities..."
rg "(clsx|classnames|cn)\(" -t tsx -t jsx -t ts -t js
# Check for files using clsx
echo "Files using clsx..."
fd -e tsx -e jsx -e ts -e js -x rg -l "from ['\"]clsx['\"]"
Length of output: 217
Script:
#!/bin/bash
# Description: Check for different className handling patterns with correct file types
# Check for template literals within clsx calls
echo "Checking for template literals within clsx..."
rg "clsx\(\`" -t tsx -t jsx -t ts -t js
# Check for direct string concatenation in className
echo "Checking for string concatenation in className..."
rg "className=\".*?\+" -t tsx -t jsx -t ts -t js
# Check for potential mixing of different className utilities
echo "Checking for mixed usage of className utilities..."
rg "from ['\"](?:clsx|classnames)['\"]" -t tsx -t jsx -t ts -t js
# List all className assignments
echo "Checking className patterns..."
rg "className=" -t tsx -t jsx -t ts -t js -C 1
Length of output: 713
Script:
#!/bin/bash
# Description: Check for different className handling patterns
# Check for template literals within clsx calls
echo "Checking for template literals within clsx..."
rg "clsx\(\`"
# Check for direct string concatenation in className
echo "Checking for string concatenation in className..."
rg "className=\".*?\+"
# Check for potential mixing of different className utilities
echo "Checking for mixed usage of className utilities..."
rg "from ['\"](?:clsx|classnames)['\"]"
# List files with className assignments
echo "Files with className patterns..."
rg -l "className="
Length of output: 10305
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
| export type CodeProps= { | ||
| children: React.ReactNode; | ||
| } | ||
|
|
||
| const Code = ({ children }: CodeProps) => { | ||
| return <code className='rui-code-root'> | ||
| return <code className={clsx('rui-code-root')}> |
There was a problem hiding this comment.
Missing: customRootClass on Code component
There was a problem hiding this comment.
Inconsistent use of class prefix - rui is an old format we had used
There was a problem hiding this comment.
ignore above comments, referenced new issues for them
| export type CardProps = { | ||
| customRootClass?: string; | ||
| className?: string; | ||
| props?: any; | ||
| } & React.ComponentProps<'div'>; | ||
|
|
||
| const Card = ({ children, className = '', customRootClass, ...props }: PropsWithChildren<CardProps>) => ( | ||
| <CardRoot className={className} customRootClass={customRootClass} {...props}> | ||
| <CardRoot className={clsx(className)} customRootClass={customRootClass} {...props}> |
| @@ -1,14 +1,14 @@ | |||
| import React, { PropsWithChildren } from 'react'; | |||
| import CardRoot from './fragments/CardRoot'; | |||
|
|
|||
| import { clsx } from 'clsx'; | |||
There was a problem hiding this comment.
can be removed since its direct usage
| @@ -15,7 +15,7 @@ export type CalloutProps = { | |||
|
|
|||
| const COMPONENT_NAME = 'Callout'; | |||
| const Callout = ({ children, className = '', color, customRootClass, ...props }: CalloutProps) => { | |||
| return (<CalloutRoot customRootClass={customRootClass} className={`${className}`} color={color ?? undefined} {...props}> | |||
| return (<CalloutRoot customRootClass={customRootClass} className={clsx(className)} color={color ?? undefined} {...props}> | |||
There was a problem hiding this comment.
dont need here since its direct usage
| @@ -11,7 +12,7 @@ export type BadgeProps = { | |||
| } | |||
|
|
|||
| const Badge = ({ children, customRootClass, className, color, ...props }: BadgeProps) => { | |||
| return <BadgeRoot customRootClass={customRootClass} className={`${className}`} color={color ?? undefined} {...props}> | |||
| return <BadgeRoot customRootClass={customRootClass} className={clsx(className)} color={color ?? undefined} {...props}> | |||
| @@ -18,7 +18,7 @@ type AvatarGroupProps = { | |||
| } | |||
|
|
|||
| const AvatarGroup = ({ avatars = [], size, customRootClass = '', className, ...props }: AvatarGroupProps) => { | |||
| return <AvatarGroupRoot customRootClass={customRootClass} className={className} {...props} > | |||
| return <AvatarGroupRoot customRootClass={customRootClass} className={clsx(className)} {...props} > | |||
| @@ -20,7 +20,7 @@ const Avatar = ({ customRootClass = '', fallback, className, src, alt, ...props | |||
| <AvatarPrimitive.Image | |||
| src={src} | |||
| alt={alt} | |||
| className={className} | |||
| className={clsx(className)} | |||
| @@ -31,7 +31,7 @@ const AlertDialogRoot = ({ children, customRootClass = '', open, onOpenChange, o | |||
| const props = { isOpen, handleOpenChange, floaterContext, rootClass, handleOverlayClick }; | |||
| return ( | |||
| <AlertDialogContext.Provider value={props}> | |||
| <div className={rootClass} > | |||
| <div className={clsx(rootClass)} > | |||
| @@ -7,7 +8,7 @@ export type AccordionHeaderProps = { | |||
|
|
|||
| const AccordionHeader: React.FC<AccordionHeaderProps> = ({ children, className = '' }) => { | |||
| return ( | |||
| <div className={className}> | |||
| <div className={clsx(className)}> | |||
This solves the issue #613 by using clsx to handle passing the className. It ensures no blank space or undefined className is passed. The files have been manually checked after the script did the migration. ** The tests would fail because main has some issues **. The tests failing are not related to components changed. Primitives have not been changed.
Summary by CodeRabbit
New Features
clsxfor improved class name management across various components.Bug Fixes
Documentation
clsxutility in relevant components to reflect the new dependency usage.