Update Docs with Composable API #1089
Conversation
WalkthroughThis update restructures several UI component documentation pages and examples, transitioning from monolithic or prop-driven APIs to a composable, compound component pattern. It introduces new API documentation files, updates example usages, and refactors code to load external source files for examples and API tables. Minor internal component improvements and dependency updates are also included. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant DocsPage
participant ExampleComponent
participant APIData
User->>DocsPage: Navigates to component docs
DocsPage->>ExampleComponent: Renders usage example (imported)
DocsPage->>APIData: Loads API documentation data (imported)
DocsPage->>User: Displays hero example and API tables
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
docs/app/docs/components/callout/docs/codeUsage.jsOops! Something went wrong! :( ESLint: 8.56.0 ESLint couldn't find the config "next/core-web-vitals" to extend from. Please check that the name of the config is correct. The config "next/core-web-vitals" was referenced from the config file in "/docs/.eslintrc.json". If you still have problems, please stop by https://eslint.org/chat/help to chat with the team. docs/app/docs/components/callout/docs/component_api/callout_icon.tsxOops! Something went wrong! :( ESLint: 8.56.0 ESLint couldn't find the config "next/core-web-vitals" to extend from. Please check that the name of the config is correct. The config "next/core-web-vitals" was referenced from the config file in "/docs/.eslintrc.json". If you still have problems, please stop by https://eslint.org/chat/help to chat with the team. ✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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: 19
🔭 Outside diff range comments (2)
docs/app/docs/components/callout/docs/codeUsage.js (1)
39-48: 💡 Verification agent🧩 Analysis chain
Consider removing or updating legacy table export
The
calloutTableis kept for backward compatibility but only contains a single property definition, which seems incomplete. Either remove it if it's no longer needed or update it to match the new API structure.
🏁 Script executed:
#!/bin/bash # Check if this legacy table is still being referenced anywhere echo "Checking for references to calloutTable in the codebase..." rg "calloutTable" --type js --type jsx --type ts --type tsxLength of output: 214
Let's widen the search to all files to ensure we catch any references:
🏁 Script executed:
#!/bin/bash echo "Searching for any references to calloutTable across the repo..." rg "calloutTable" -n .Length of output: 245
Remove unused legacy
calloutTableexportThe
calloutTabledefinition in
docs/app/docs/components/callout/docs/codeUsage.js
is not referenced anywhere in the repository. You can safely delete this export (and any related imports) to clean up dead code.docs/app/docs/components/avatar/docs/codeUsage.js (1)
28-41: 💡 Verification agent🧩 Analysis chain
Consider deprecating or removing
avatarBasicUsageExample.Since you're now using the more detailed API documentation in
api_documentation, consider either removing theavatarBasicUsageExampleobject or adding a deprecation comment if it's still needed for backward compatibility.
🏁 Script executed:
#!/bin/bash # Check if avatarBasicUsageExample is still used anywhere in the codebase echo "Checking for usages of avatarBasicUsageExample..." rg --type js --type jsx --type tsx "avatarBasicUsageExample" docsLength of output: 202
🏁 Script executed:
#!/bin/bash # Retry search without type filters to locate any references echo "Searching for avatarBasicUsageExample across the docs directory..." rg -n "avatarBasicUsageExample" docsLength of output: 386
Action Required: Remove or Deprecate
avatarBasicUsageExampleAcross Docs
avatarBasicUsageExampleis still referenced in the MDX page and cannot be removed in isolation.• docs/app/docs/components/avatar/docs/codeUsage.js:28
– Export ofavatarBasicUsageExample
• docs/app/docs/components/avatar/page.mdx:3
–import { avatarBasicUsageExample }
– Usage in the component’s propsPlease either:
- Remove
avatarBasicUsageExampleexport and delete its import/usage inpage.mdx, updating the page to rely solely onapi_documentation;- Or mark
avatarBasicUsageExampleas @deprecated incodeUsage.jsand add a deprecation notice inpage.mdxfor backward‐compatibility.
🧹 Nitpick comments (31)
docs/app/docs/components/blockquote/examples/BlockQuoteExample.tsx (1)
1-11: LGTM - Clean implementation of example component.The component is well-structured and follows React functional component patterns. It clearly demonstrates the BlockQuote component with appropriate props and content.
Consider adding TypeScript prop type definitions for improved type safety, even though this is a simple example component:
+interface BlockQuoteExampleProps {} -const BlockQuoteExample = () => ( +const BlockQuoteExample: React.FC<BlockQuoteExampleProps> = () => ( <div className="text-gray-950"> <BlockQuote color="green"> "Behind every great man is a woman rolling her eyes." — Jim Carrey </BlockQuote> </div> )docs/app/docs/components/switch/docs/examples/SwitchExample.tsx (1)
5-8: Consider adding an accessible label.
The Switch example currently renders without an accessible label or ARIA attribute, which can make it difficult for screen reader users. You could enhance accessibility by adding anaria-labelor a visually hidden label, for example:<Switch.Root aria-label="Enable notifications"> <Switch.Thumb /> </Switch.Root>src/components/ui/Avatar/fragments/AvatarImage.tsx (1)
13-16: Merge user-provided className with the default.
Currently, anyclassNamepassed inpropswill be overridden by the defaultclsxcall. To preserve user-supplied classes, destructureclassNameand merge it:- const AvatarImage = ({ src = '', alt = '', ...props }: AvatarImageProps) => { - const { rootClass } = useContext(AvatarContext); - return <AvatarPrimitiveImage className={clsx(`${rootClass}-image`)} src={src} alt={alt} {...props} />; + const AvatarImage = ({ src = '', alt = '', className, ...props }: AvatarImageProps) => { + const { rootClass } = useContext(AvatarContext); + return ( + <AvatarPrimitiveImage + className={clsx(`${rootClass}-image`, className)} + src={src} + alt={alt} + {...props} + /> + );docs/app/docs/components/avatar/page.mdx (2)
3-3: Remove unused import.
avatarBasicUsageExampleis imported but no longer used in this file—please remove it to clean up the code.
25-27: Enhance documentation structure with a section heading.
To clearly delineate the API reference from the rest of the content, consider adding an explicit section heading (e.g.,<h2>API Documentation</h2>or a<Documentation.SectionTitle>component) above these tables.docs/app/docs/components/progress/docs/api/root.tsx (1)
45-49: Consider renaming "customRootClass" to "className".For better consistency with React conventions and other components in your design system, consider renaming the
customRootClassprop toclassName.- name: "customRootClass", - info_tooltips: "Custom root class name to override default styling." + name: "className", + info_tooltips: "Custom class name to override default styling."docs/app/docs/components/progress/docs/examples/ProgressExample.tsx (2)
7-7: Consider using a CSS class instead of inline style.For better maintainability and separation of concerns, consider using a CSS class instead of an inline style for setting the width.
- <Card style={{width: "90%"}}> + <Card className="w-90">
15-15: Remove unnecessary empty line.There's an empty line at the end of the file that could be removed to keep the code clean.
docs/app/docs/components/avatar-group/page.mdx (1)
5-5: Combine imports from codeUsage for clarity.Importing from
./docs/codeUsagetwice can be consolidated:-import codeUsage, { anatomy } from "./docs/codeUsage"; -import { api_documentation } from "./docs/codeUsage"; +import codeUsage, { anatomy, api_documentation } from "./docs/codeUsage";docs/app/docs/components/avatar-group/docs/api/avatar.tsx (1)
2-17: Consistent formatting for object literals.Normalize spacing around colons (
key: valuevskey : value) to match other API modules.docs/app/docs/components/callout/docs/api/text.tsx (1)
1-38: Well-structured API documentation for the Text componentThe documentation schema effectively defines the component's props with appropriate types, descriptions, and default values. This modular approach to documentation will make it easier for developers to understand the specific role of the Text subcomponent within the Callout composite.
Consider adding a default value for the
classNameprop if one exists, rather than using "--" placeholder.}, type: 'string', - default: '--', + default: "''", }docs/app/docs/components/switch/docs/api/thumb.tsx (1)
1-38: Clear and comprehensive API documentation for the Thumb componentThe API documentation is well-structured with appropriate props, types, and descriptions. Good job including default values for each prop, which helps developers understand the component's behavior out of the box.
I noticed that line 40 exists but is blank. Consider removing this unnecessary line.
export default data; -docs/app/docs/components/callout/docs/api/icon.tsx (1)
1-38: Well-structured API documentationThe API documentation for the Callout Icon component is well-organized with clear descriptions and properly formatted props. The structure follows the established pattern for component documentation.
However, consider adding default values for the className prop if one exists in the implementation, rather than using "--" placeholder. If there truly is no default, the current approach is fine.
docs/app/docs/components/avatar/docs/api/image.tsx (1)
1-38: Consistent API documentation structureThe Avatar Image API documentation follows the same structured approach as other components, with clear prop descriptions and types. This consistency in documentation is valuable for developers using the component library.
Consider clarifying whether the src and alt props are required, since they have no default values but are essential for proper image rendering and accessibility.
src/components/ui/Callout/fragments/CalloutRoot.tsx (1)
12-12: Redundant type annotationThe type definition
string | ''is redundant since an empty string is already a string type. Consider simplifying to juststring.- className?: string | '' ; + className?: string;docs/app/docs/components/avatar-group/docs/api/root.tsx (1)
1-62: Add TypeScript type definitions for documentation structure.Consider adding TypeScript interfaces or types for the documentation data structure. This would provide type safety and make the documentation more maintainable.
interface PropInfo { name: string; info_tooltips: string; } interface PropData { prop: PropInfo; type: string | React.ReactNode; default: string; } interface ComponentDocumentation { name: string; description: string; columns: Array<{name: string, id: string}>; data: PropData[]; } const data: ComponentDocumentation = { // Your existing data }docs/app/docs/components/switch/docs/api/root.tsx (1)
1-38: Add TypeScript type definitions for the documentation structure.For consistency with TypeScript best practices, consider adding type definitions for the documentation data structure:
interface PropInfo { name: string; info_tooltips: string; } interface PropData { prop: PropInfo; type: string; default: string | null; } interface ComponentDocumentation { name: string; description: string; columns: Array<{name: string, id: string}>; data: PropData[]; } const data: ComponentDocumentation = { // Your existing data }docs/components/layout/Documentation/helpers/ComponentFeatures/ComponentFeatures.js (2)
23-23: Consider using design tokens instead of hardcoded colors.The hardcoded color values could be replaced with design tokens or CSS variables for better maintainability:
- <span className="text-green-950 w-[24px] h-[24px] bg-green-500 rounded-full flex items-center justify-center p-1"> + <span className="text-success-foreground w-[24px] h-[24px] bg-success rounded-full flex items-center justify-center p-1">This makes it easier to maintain consistent theming across the application.
22-29: Enhance list item accessibility.The list item structure could benefit from additional accessibility attributes to better indicate the relationship between the icon and text:
- <li className="flex items-center space-x-2" key={index}> + <li className="flex items-center space-x-2" key={index} aria-labelledby={`feature-${index}`}> <span className="text-green-950 w-[24px] h-[24px] bg-green-500 rounded-full flex items-center justify-center p-1"> <TickIcon /> </span> - <span> + <span id={`feature-${index}`}> {feature} </span> </li>This improves the association between the icon and the feature text for screen readers.
docs/app/docs/components/switch/page.mdx (2)
3-3: Clean up spacing and formatting.There's inconsistent spacing in the imports and throughout the document with multiple empty lines that could be cleaned up:
import Documentation from "@/components/layout/Documentation/Documentation" import Switch from "@radui/ui/Switch" -import codeUsage, { api_documentation } from "./docs/codeUsage" +import codeUsage, { api_documentation } from "./docs/codeUsage" import switchMetadata from "./seo" -import SwitchExample from "./docs/examples/SwitchExample" +import SwitchExample from "./docs/examples/SwitchExample" export const metadata = switchMetadata; - - - - <Documentation title='Switch' description={` Switch is used to toggle between two states on and off. It is commonly used in settings panel, forms and any other place where a user needs to enable or disable feature. `}> <Documentation.ComponentHero codeUsage={codeUsage}> <SwitchExample /> </Documentation.ComponentHero> - {/* API Documentation */} - <Documentation.Table title="Root" description={api_documentation.root.description} columns={api_documentation.root.columns} data={api_documentation.root.data} /> - <Documentation.Table title="Thumb" description={api_documentation.thumb.description} columns={api_documentation.thumb.columns} data={api_documentation.thumb.data} /> - - - + {/* API Documentation */} + <Documentation.Table + title="Root" + description={api_documentation.root.description} + columns={api_documentation.root.columns} + data={api_documentation.root.data} + /> + <Documentation.Table + title="Thumb" + description={api_documentation.thumb.description} + columns={api_documentation.thumb.columns} + data={api_documentation.thumb.data} + /> </Documentation>Consistent spacing and indentation will improve code readability.
Also applies to: 6-7, 11-14, 23-26
24-25: Add type checking for API documentation data.Consider adding runtime validation or TypeScript type guards to ensure the api_documentation structure matches what's expected by the Documentation.Table component. This would help catch errors if the structure changes:
// Example validation function const validateApiDoc = (doc) => { if (!doc || !doc.description || !doc.columns || !doc.data) { console.error('Invalid API documentation structure', doc); return false; } return true; }; // Usage in component {validateApiDoc(api_documentation.root) && ( <Documentation.Table title="Root" description={api_documentation.root.description} columns={api_documentation.root.columns} data={api_documentation.root.data} /> )}docs/app/docs/components/callout/examples/CalloutSizes.tsx (2)
7-7: Remove unusedvariantsarrayThe
variantsarray is defined but never used in the component rendering. Consider removing this unused variable to clean up the code.- const variants = ['soft', 'outline'];
8-10: Simplify nested flex containersThe current implementation has two nested flex containers with similar styling. Consider simplifying to a single flex container for better code maintainability.
- return <div className='flex flex-col gap-4'> - - <div className='flex flex-col gap-4 justify-center flex-wrap'> + return <div className='flex flex-col gap-4 justify-center'>docs/app/docs/components/avatar/docs/api/root.tsx (2)
25-26: Consider providing actual default values instead of "--"Using "--" for default values that don't exist could be confusing. Consider using "None" or "undefined" for better clarity.
- default : "--", + default : "None",Also applies to: 33-34
57-58: Standardize empty string representationThe empty string defaults are represented as backticks (``) which is inconsistent with other default values. Consider standardizing to single quotes or explicitly stating "Empty String".
- default: '``', + default: "''",Also applies to: 65-66, 73-74
docs/app/docs/components/toggle-group/docs/api/root.tsx (3)
34-34: Consider using consistent formatting for default values.The default value for className is wrapped in quotes (
''), which is inconsistent with other string defaults like"null"(lines 60 and 68). Consider standardizing the formatting across all default values.- default: "''", + default: "\"\"",
52-53: Fix indentation inconsistency.There's an indentation issue at the end of this object that creates inconsistent code formatting.
- }, - + },
70-71: Remove unnecessary empty line.There's an extra blank line between object entries that breaks the consistent spacing pattern used elsewhere in the file.
- }, - + },docs/app/docs/components/avatar-group/docs/api/item.tsx (1)
18-35: Ensure consistent spacing in object structure.The indentation and spacing within the data array objects is inconsistent. Consider standardizing the formatting for better readability.
data:[ { - prop : { - name : "color", - info_tooltips : "The color of the AvatarGroupItem." - }, - type : "string", - default : "--", + prop: { + name: "color", + info_tooltips: "The color of the AvatarGroupItem." + }, + type: "string", + default: "--", }, { - prop : { - name : "children", - info_tooltips : "The children of the AvatarGroupItem." - }, - type : "React.ReactNode", - default : "--", + prop: { + name: "children", + info_tooltips: "The children of the AvatarGroupItem." + }, + type: "React.ReactNode", + default: "--", } ]docs/app/docs/components/avatar-group/docs/api/fallback.tsx (1)
18-27: Ensure consistent spacing in object structure.The indentation and spacing within the data array objects is inconsistent compared to other API documentation files. Consider standardizing the formatting for better readability.
data:[ { - prop : { - name : "children", - info_tooltips : "The children of the AvatarFallback." - }, - type : "React.ReactNode", - default : "--", + prop: { + name: "children", + info_tooltips: "The children of the AvatarFallback." + }, + type: "React.ReactNode", + default: "--", } ]docs/app/docs/components/callout/examples/CalloutVariants.tsx (1)
19-21: Remove console.log statementThe console.log statement appears to be a debugging artifact and should be removed before production.
- {calloutVariants.map((variant,idx) => { - console.log(variant); - return <span key={idx}> + {calloutVariants.map((variant,idx) => ( + <span key={idx}>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
docs/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (52)
docs/app/docs/components/avatar-group/docs/api/avatar.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/api/fallback.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/api/item.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/api/root.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/avatarGroup_anatomy.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/codeUsage.js(2 hunks)docs/app/docs/components/avatar-group/docs/example_1.tsx(1 hunks)docs/app/docs/components/avatar-group/page.mdx(2 hunks)docs/app/docs/components/avatar/docs/AvatarExample.tsx(1 hunks)docs/app/docs/components/avatar/docs/api/fallback.tsx(1 hunks)docs/app/docs/components/avatar/docs/api/image.tsx(1 hunks)docs/app/docs/components/avatar/docs/api/root.tsx(1 hunks)docs/app/docs/components/avatar/docs/codeUsage.js(1 hunks)docs/app/docs/components/avatar/page.mdx(2 hunks)docs/app/docs/components/blockquote/docs/codeUsage.js(1 hunks)docs/app/docs/components/blockquote/examples/BlockQuoteExample.tsx(1 hunks)docs/app/docs/components/blockquote/page.mdx(2 hunks)docs/app/docs/components/callout/docs/api/callout.tsx(0 hunks)docs/app/docs/components/callout/docs/api/icon.tsx(1 hunks)docs/app/docs/components/callout/docs/api/root.tsx(1 hunks)docs/app/docs/components/callout/docs/api/text.tsx(1 hunks)docs/app/docs/components/callout/docs/codeUsage.js(1 hunks)docs/app/docs/components/callout/examples/CalloutColor.tsx(1 hunks)docs/app/docs/components/callout/examples/CalloutExample.tsx(1 hunks)docs/app/docs/components/callout/examples/CalloutSizes.tsx(1 hunks)docs/app/docs/components/callout/examples/CalloutVariants.tsx(2 hunks)docs/app/docs/components/callout/page.mdx(3 hunks)docs/app/docs/components/progress/docs/api/indicator.tsx(1 hunks)docs/app/docs/components/progress/docs/api/root.tsx(1 hunks)docs/app/docs/components/progress/docs/codeUsage.js(1 hunks)docs/app/docs/components/progress/docs/examples/ProgressExample.tsx(1 hunks)docs/app/docs/components/progress/page.mdx(2 hunks)docs/app/docs/components/switch/docs/api/root.tsx(1 hunks)docs/app/docs/components/switch/docs/api/thumb.tsx(1 hunks)docs/app/docs/components/switch/docs/codeUsage.js(1 hunks)docs/app/docs/components/switch/docs/examples/SwitchExample.tsx(1 hunks)docs/app/docs/components/switch/page.mdx(2 hunks)docs/app/docs/components/toggle-group/docs/api/item.tsx(1 hunks)docs/app/docs/components/toggle-group/docs/api/root.tsx(1 hunks)docs/app/docs/components/toggle-group/docs/codeUsage.js(1 hunks)docs/app/docs/components/toggle-group/docs/examples/ToggleGroupExample.tsx(1 hunks)docs/app/docs/components/toggle-group/page.mdx(2 hunks)docs/components/layout/Documentation/helpers/ComponentFeatures/ComponentFeatures.js(1 hunks)docs/components/layout/Documentation/helpers/DocsTable.js(1 hunks)docs/package.json(1 hunks)src/components/ui/Avatar/fragments/AvatarFallback.tsx(1 hunks)src/components/ui/Avatar/fragments/AvatarImage.tsx(1 hunks)src/components/ui/AvatarGroup/fragments/AvatarGroupRoot.tsx(1 hunks)src/components/ui/Callout/Callout.tsx(0 hunks)src/components/ui/Callout/fragments/CalloutRoot.tsx(1 hunks)src/components/ui/Progress/stories/Progress.stories.tsx(0 hunks)styles/themes/components/switch.scss(1 hunks)
💤 Files with no reviewable changes (3)
- src/components/ui/Progress/stories/Progress.stories.tsx
- src/components/ui/Callout/Callout.tsx
- docs/app/docs/components/callout/docs/api/callout.tsx
🧰 Additional context used
🧬 Code Graph Analysis (7)
docs/app/docs/components/avatar-group/docs/example_1.tsx (1)
docs/app/docs/components/avatar-group/docs/avatarGroup_anatomy.tsx (1)
AvatarGroup(3-12)
docs/components/layout/Documentation/helpers/ComponentFeatures/ComponentFeatures.js (1)
docs/components/layout/Documentation/utils.js (2)
BookMarkLink(7-40)BookMarkLink(7-40)
src/components/ui/Avatar/fragments/AvatarFallback.tsx (2)
src/core/primitives/Avatar/fragments/AvatarPrimitiveFallback.tsx (1)
AvatarPrimitiveFallbackProps(5-9)src/components/ui/Avatar/contexts/AvatarContext.tsx (1)
AvatarContext(9-14)
docs/app/docs/components/callout/examples/CalloutSizes.tsx (1)
docs/app/docs/components/callout/examples/CalloutExample.tsx (1)
BookmarkIcon(5-7)
docs/app/docs/components/avatar-group/docs/codeUsage.js (4)
docs/app/docs/components/callout/docs/codeUsage.js (2)
api_documentation(23-27)api_documentation(23-27)docs/app/docs/components/blockquote/docs/codeUsage.js (2)
api_documentation(18-20)api_documentation(18-20)docs/app/docs/components/avatar/docs/codeUsage.js (2)
api_documentation(22-26)api_documentation(22-26)docs/app/docs/components/accordion/docs/codeUsage.js (2)
api_documentation(29-33)api_documentation(29-33)
docs/app/docs/components/callout/examples/CalloutVariants.tsx (1)
docs/app/docs/components/callout/examples/CalloutExample.tsx (1)
BookmarkIcon(5-7)
docs/app/docs/components/callout/examples/CalloutColor.tsx (1)
docs/app/docs/components/callout/examples/CalloutExample.tsx (1)
BookmarkIcon(5-7)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: build
- GitHub Check: lint
🔇 Additional comments (61)
docs/app/docs/components/blockquote/page.mdx (2)
10-10: LGTM - Good modularization of example component.The import of the BlockQuoteExample component follows best practices for code organization by extracting example components into dedicated files.
20-20: LGTM - Clean implementation of component reuse.Moving from an inline BlockQuote implementation to a reusable example component improves maintainability and consistency across the documentation.
docs/app/docs/components/blockquote/docs/codeUsage.js (4)
1-1: LGTM - Good utility import.Using the utility function for parsing source code enables a consistent approach across all component documentation.
3-6: LGTM - Good approach to dynamically loading example code.Dynamically loading source code from actual example files ensures that the documentation always shows the current implementation, maintaining a single source of truth.
10-11: LGTM - Using dynamically loaded source code.Replacing hardcoded code examples with dynamically loaded files improves maintainability and ensures the documentation stays in sync with the actual implementation.
Also applies to: 13-14
1-6:❓ Verification inconclusive
Verify that top-level await is supported in your environment.
This file uses top-level await for asynchronously loading source code files. While this works in Node.js ESM modules and is supported by Next.js, it's worth ensuring compatibility with your current build setup.
🏁 Script executed:
#!/bin/bash # Check if package.json has type: "module" or if Next.js config supports top-level await grep -E '"type":\s*"module"|moduleType' package.json grep -E 'webpack|experimental' next.config.jsLength of output: 170
🏁 Script executed:
#!/bin/bash # Verify ESM, frameworks, and bundlers to ensure top-level await support grep -n '"type":\s*"module"' package.json || echo "→ no ESM declaration" grep -n '"next"' package.json || echo "→ no Next.js dependency" grep -n '"@docusaurus"' package.json || echo "→ no Docusaurus dependency" grep -n '"webpack"' package.json || echo "→ no webpack dependency" grep -n '"vite"' package.json || echo "→ no vite dependency" find . -maxdepth 2 -type f -name 'next.config.*' -print || echo "→ no Next.js config file"Length of output: 511
🏁 Script executed:
#!/bin/bash # Inspect docs site configuration for ESM and Next.js settings echo "🔍 Finding package.json in docs/ directory:" find docs -maxdepth 2 -type f -name 'package.json' -print echo -e "\n📄 docs/package.json (first 50 lines):" sed -n '1,50p' docs/package.json echo -e "\n🔍 Checking ESM declaration and dependencies in docs/package.json:" grep -n '"type":' docs/package.json || echo "→ no type field" grep -n '"next"' docs/package.json || echo "→ no Next.js dependency" grep -n '"webpack"' docs/package.json || echo "→ no webpack dependency" grep -n '"vite"' docs/package.json || echo "→ no vite dependency" echo -e "\n📄 docs/next.config.js (first 200 lines):" sed -n '1,200p' docs/next.config.js || echo "→ docs/next.config.js not found"Length of output: 2538
Verify top-level await compatibility in your docs site build
File:
docs/app/docs/components/blockquote/docs/codeUsage.js(lines 1–6)This module relies on a top-level await to load example source files:
import { getSourceCodeFromPath } from '@/utils/parseSourceCode'; const example_1_SourceCode = await getSourceCodeFromPath(`docs/app/docs/components/blockquote/examples/BlockQuoteExample.tsx`); const scss_SourceCode = await getSourceCodeFromPath('styles/themes/components/blockquote.scss');Our documentation site is powered by Next.js v15.2.3 with
@next/mdx. Itsdocs/package.jsonhas no"type": "module"anddocs/next.config.jsis CommonJS, so while SWC typically handles top-level await in server components, please:
- Run
npm run build(ornext build) to ensure there are no syntax errors.- If the build fails, consider wrapping these calls in an async IIFE or converting this module into an async server component.
styles/themes/components/switch.scss (1)
25-27: The addition of a blank line here is purely stylistic and does not affect functionality. The separation improves readability.docs/app/docs/components/progress/docs/api/root.tsx (2)
2-3: LGTM! Clear and accurate component renaming.Renaming from "Progress" to "Root" with the updated description properly clarifies this as the root component for Progress, aligning with the composable API pattern being implemented across components.
18-50: LGTM! Props are well-defined with clear descriptions.The props table provides clear type information, default values, and helpful tooltips for each prop. The removal of "color" and "renderLabel" props (as noted in the AI summary) aligns with the API restructuring.
docs/app/docs/components/avatar/docs/AvatarExample.tsx (1)
5-8: LGTM! Well-implemented composition pattern.The refactoring to use
Avatar.Root,Avatar.Image, andAvatar.Fallbackcomponents creates a more explicit and flexible composition pattern, aligning with modern React component design best practices.docs/app/docs/components/progress/docs/examples/ProgressExample.tsx (1)
5-13: LGTM! Clear example demonstrating the new composition pattern.The example effectively demonstrates the new Progress component structure with Root and Indicator subcomponents.
docs/components/layout/Documentation/helpers/DocsTable.js (1)
58-59: LGTM! Good defensive programming practice.Adding a default empty array for the
enumValuesprop prevents potential runtime errors when this prop is undefined or null. This enhances the robustness of the code, especially important for documentation components that need to handle various data structures.docs/app/docs/components/avatar-group/page.mdx (1)
20-23: API tables integration is correct.The four
<Documentation.Table>entries correctly render the modular API docs for Root, Item, Avatar, and Fallback using theapi_documentationobject.docs/app/docs/components/toggle-group/docs/api/item.tsx (1)
1-38: New API metadata is accurate.The
dataobject correctly defines the ToggleGroup Item props, column schema, and default values. It follows the established pattern and has no issues.docs/app/docs/components/progress/docs/api/indicator.tsx (1)
1-28: Indicator API metadata is well-defined.The new documentation object for the
Indicatorcomponent accurately specifies its prop schema, defaults, and description. No issues found.docs/app/docs/components/progress/page.mdx (3)
6-7: Good addition of a separate example componentMoving to using a dedicated example component (
ProgressExample) makes the code more maintainable and follows the component composition pattern used throughout the documentation.
16-17: LGTM - Clean usage of imported example componentUsing the imported
ProgressExamplecomponent keeps the documentation page cleaner and more maintainable compared to having inline examples.
24-27: Well-structured API documentation with component compositionBreaking the API documentation into separate tables for Root and Indicator components follows good component composition principles. This makes the documentation more granular and easier to understand, especially for developers new to the component.
docs/app/docs/components/callout/page.mdx (3)
5-6: Good modularization with separate example componentAdding the separate
CalloutExamplecomponent follows the pattern of modularizing examples across the documentation system.
23-24: Clean usage of example componentUsing the imported
CalloutExamplecomponent instead of an inline implementation keeps the documentation page cleaner.
47-52: Well-structured API documentation using composable patternThe API documentation is now properly broken down into Root, Icon, and Text components, making it clearer for developers to understand the component structure. This composition-based approach aligns well with the composable API pattern being implemented across the documentation.
docs/app/docs/components/toggle-group/page.mdx (3)
3-4: Good modularization of imports and structureThe updated imports shift toward a more modular approach by:
- Simplifying the base import
- Adding the structured
api_documentationobject- Including the more comprehensive
ToggleGroupExamplecomponentThis approach is consistent with the improved documentation pattern across the codebase.
Also applies to: 7-9
19-20: Updated to use the new example componentSwitching from
ToggleGroupExampleBasictoToggleGroupExamplealigns this documentation with the updated component examples pattern.
22-25: Well-structured API documentation with component compositionBreaking down the API documentation into Root and Item tables provides a clearer structure that follows the composable API pattern, making it more intuitive for developers to understand the component's usage.
src/components/ui/Avatar/fragments/AvatarFallback.tsx (3)
9-11: Good type extension for better prop customizationCreating a new type that extends
AvatarPrimitiveFallbackPropswith an optionalclassNameprop follows good TypeScript practices and enables proper component customization.
13-13: Added default value for className - good practiceAdding a default empty string for
classNameis a good defensive programming practice, ensuring the component behaves predictably even when the prop is not provided.
15-15: Proper class merging with clsxUsing
clsxto merge the component's base class with the customclassNameensures styles are properly combined without conflicts. This allows for external styling customization while maintaining the component's core styling.docs/app/docs/components/avatar-group/docs/avatarGroup_anatomy.tsx (1)
6-9: The updated composable component structure looks clean and intuitive.The hierarchy has been improved with more semantically named components replacing the previous nested structure. The new pattern with
Item,Avatar, andFallbackis more intuitive and consistent with modern component composition patterns.docs/app/docs/components/avatar-group/docs/example_1.tsx (2)
1-1: Good addition of the "use client" directiveThis correctly marks the component as a client component for Next.js, ensuring it will be properly handled during rendering.
5-18: Well-implemented composable pattern with clear API usageThe example effectively demonstrates the new component structure with multiple avatar items. Each item is properly configured with color, avatar image source, and fallback content, showcasing the flexibility of the new API.
docs/app/docs/components/callout/examples/CalloutExample.tsx (1)
1-20: Good implementation of the composable Callout component patternThe example clearly demonstrates the usage of the Callout component with its composable parts (Root, Icon, and Text). The code is well-structured and includes the necessary "use client" directive.
docs/app/docs/components/avatar/docs/api/fallback.tsx (2)
22-23: Correct tooltip labelThe tooltip correctly identifies this as AvatarFallback, which confirms that the component name should be "Fallback" rather than "Image".
29-31: Correct tooltip labelThe tooltip correctly identifies this as AvatarFallback, matching the expected purpose of this file.
src/components/ui/AvatarGroup/fragments/AvatarGroupRoot.tsx (1)
16-16: Good practice: Default value for className propAdding a default empty string for the className prop is a good practice. This ensures that className is always a string when passed to the clsx function, preventing potential issues with undefined values.
docs/app/docs/components/toggle-group/docs/examples/ToggleGroupExample.tsx (3)
1-20: Well-structured SVG icon componentsThe SVG icon components are well-defined with proper viewBox and paths, making them suitable for use in the toggle group items.
35-41: Good implementation of composable ToggleGroup patternThe example effectively demonstrates the composable pattern using ToggleGroup.Root and ToggleGroup.Item components with proper key and value props.
21-27: Well-structured items arrayThe items array is well-structured, pairing SVG icons with values, which allows for a clean mapping to ToggleGroup.Item components.
docs/app/docs/components/switch/docs/codeUsage.js (2)
1-15: Good refactoring to use dynamic source code loadingThe refactoring to load example code and styles from external files improves maintainability and organization. Creating a structured API documentation object with separate modules for different component parts (root and thumb) follows good modular design principles.
20-24: Appropriate update of code referencesThe code object has been correctly updated to reference the dynamically loaded source code instead of hardcoded strings, which is consistent with the refactoring approach.
src/components/ui/Callout/fragments/CalloutRoot.tsx (1)
21-21: Good practice: Added default values for string propsAdding explicit default values for
classNameandcustomRootClassprops is a good practice that prevents potential issues with undefined values during class name concatenation. This makes the component more robust and predictable.docs/app/docs/components/callout/docs/codeUsage.js (2)
8-10: Great use of dynamic source code loadingThe use of
getSourceCodeFromPathto asynchronously load example source code and styles is a good practice for maintainability and code organization.
23-27: Well-structured API documentation exportsBreaking down the API documentation into separate components (root, icon, text) aligns well with the compound component pattern and improves documentation clarity.
docs/app/docs/components/callout/docs/api/root.tsx (1)
22-23: Consistent component references in tooltipsThe tooltip correctly references "CalloutRoot" which is good, but make sure this consistency is maintained throughout the file.
docs/app/docs/components/toggle-group/docs/api/root.tsx (1)
1-82: LGTM! Well-structured API documentation for the ToggleGroup Root component.The file establishes a clean and consistent format for documenting component API props, with appropriate columns for props, types, and default values. This structured approach will enhance the documentation's maintainability and readability.
docs/app/docs/components/avatar-group/docs/api/item.tsx (1)
1-38: LGTM! Well-structured API documentation for the AvatarGroup Image component.The documentation structure looks good with clear props, types, and default values.
docs/app/docs/components/avatar-group/docs/api/fallback.tsx (1)
1-30: LGTM! Well-structured API documentation for the Avatar Fallback component.The documentation structure is clear with appropriate props, types, and default values.
docs/app/docs/components/avatar/docs/codeUsage.js (3)
1-5: LGTM! Good refactoring to use dynamically loaded source code.Replacing hardcoded examples with dynamically loaded code via
getSourceCodeFromPathimproves maintainability and keeps the documentation in sync with actual component examples.
8-10: LGTM! Good modularization of API documentation.Importing separate API documentation modules for each subcomponent creates a cleaner structure and better separation of concerns.
22-26: LGTM! Well-organized API documentation export structure.The
api_documentationexport provides a clean way to access the documentation for each subcomponent.docs/app/docs/components/toggle-group/docs/codeUsage.js (3)
1-5: Good refactoring to dynamic source code loadingThis change improves maintainability by using the
getSourceCodeFromPathutility to load example code and styles from external files instead of defining them inline.
8-15: Great modularization of API documentationBreaking down the API documentation into separate modules for root and item components aligns with a composable pattern, making the documentation more maintainable and easier to update when component changes occur.
17-24: Clean code structure for examplesThe code structure is clean and straightforward, utilizing the external source files effectively. This organization will make future updates simpler.
docs/app/docs/components/callout/examples/CalloutVariants.tsx (3)
1-1: Good addition of client directiveAdding "use client" is appropriate since this component will render on the client side.
6-6: Improved import organizationUpdating the import path to use the local BookmarkIcon from CalloutExample provides better component organization.
22-29: Good implementation of composable patternThe refactoring to use Callout.Root, Callout.Icon, and Callout.Text follows the composable component pattern, making the component structure more explicit and easier to understand.
docs/app/docs/components/progress/docs/codeUsage.js (3)
2-9: Excellent separation of API documentation and dynamic loadingThis change properly separates the Progress component API into root and indicator parts while also implementing dynamic loading of example code and styles from external files. This approach improves maintainability and consistency.
13-18: Clean implementation of code examplesUsing dynamically loaded source code for both JavaScript examples and CSS simplifies maintenance and keeps the documentation file clean.
24-25: Appropriate API documentation structureThe separation of API documentation into root and indicator components reflects the composable nature of the Progress component, making it easier for developers to understand the component's structure.
docs/app/docs/components/callout/examples/CalloutColor.tsx (3)
1-3: Good client directive and import updatesAdding the "use client" directive and updating imports to match the new component structure is appropriate.
6-9: Improved demonstration of color variantsSimplifying the component to focus only on demonstrating color variations makes this example more focused and easier to understand.
10-17: Well-structured composable component usageUsing the composable pattern with Callout.Root, Callout.Icon, and Callout.Text provides a clear structure and demonstrates the proper usage of the component. This is consistent with the changes in CalloutVariants.tsx.
| "@next/mdx": "^15.2.0", | ||
| "@radui/fx": "^0.2.0", | ||
| "@radui/ui": "^0.0.38", | ||
| "@radui/ui": "^0.0.39", |
There was a problem hiding this comment.
Commit lockfile update for dependency bump.
When bumping @radui/ui to a new version, ensure that the lockfile (package-lock.json, yarn.lock, or pnpm-lock.yaml) is regenerated and committed to avoid drift between package.json and installed dependencies.
| import root_api_SourceCode from './api/root.tsx'; | ||
| import item_api_SourceCode from './api/item.tsx'; | ||
| import avatar_api_SourceCode from './api/avatar.tsx'; | ||
| import fallback_api_SourceCode from './api/fallback.tsx'; |
There was a problem hiding this comment.
Critical: imports must precede all code.
ESM requires all import statements at the top level before any executable code. These API imports are currently placed after await calls, which will throw a syntax error. Please move them above the first await:
-const example_1_SourceCode = await getSourceCodeFromPath(...);
-import root_api_SourceCode from './api/root.tsx';
-import item_api_SourceCode from './api/item.tsx';
-import avatar_api_SourceCode from './api/avatar.tsx';
-import fallback_api_SourceCode from './api/fallback.tsx';
+import root_api_SourceCode from './api/root.tsx';
+import item_api_SourceCode from './api/item.tsx';
+import avatar_api_SourceCode from './api/avatar.tsx';
+import fallback_api_SourceCode from './api/fallback.tsx';
+const example_1_SourceCode = await getSourceCodeFromPath(...);Committable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
docs/app/docs/components/avatar-group/docs/api/item.tsx (1)
1-38: Inconsistent spacing in object property definitions.There's inconsistent spacing around colons in the object properties throughout the file. Standardizing this would improve code consistency.
- name : "Item", + name: "Item", - description : "The item component for the AvatarGroup.", + description: "The item component for the AvatarGroup.", - columns : [ + columns: [ // ... (apply similar changes throughout the file)
🧹 Nitpick comments (5)
docs/app/docs/components/avatar-group/docs/api/avatar.tsx (3)
1-38: Inconsistent spacing in object property definitions.There's inconsistent spacing around colons in the object properties. Some have spaces before and after the colon (e.g.,
name : "Avatar"), while others have space only after (e.g.,name: "Default"). Standardizing this would improve code consistency.- name : "Avatar", + name: "Avatar", - description : "The avatar component for the AvatarGroup.", + description: "The avatar component for the AvatarGroup.", - columns : [ + columns: [ - name : "Prop", + name: "Prop", - id : "prop", + id: "prop", // ... (apply similar changes throughout the file)
18-35: Consider adding TypeScript interfaces for the data structure.The file could benefit from TypeScript interfaces to define the structure of the API documentation data. This would provide better type safety, autocompletion in IDEs, and make the code more maintainable.
interface PropDefinition { name: string; info_tooltips: string; } interface PropData { prop: PropDefinition; type: string; default: string; } interface ColumnDefinition { name: string; id: string; } interface ComponentApiData { name: string; description: string; columns: ColumnDefinition[]; data: PropData[]; } const data: ComponentApiData = { // ... existing data };
22-22: Consider renaminginfo_tooltipsto singular form.The property
info_tooltipsis plural but contains a single string value. Consider renaming it toinfo_tooltipfor better semantic accuracy, or ensure it's designed to accept an array of tooltips if pluralization is intentional.- info_tooltips : "The source of the avatar." + info_tooltip: "The source of the avatar."Also applies to: 30-30
docs/app/docs/components/avatar-group/docs/api/item.tsx (2)
32-32: Consider adding more specific type information for "children".The type for the "children" prop is specified as a string "React.ReactNode". When building the actual component, make sure to properly type this using TypeScript's type system rather than treating it as a string.
If implementing TypeScript interfaces as suggested in the previous file, this would become:
interface PropData { prop: PropDefinition; type: string; // For documentation display purposes default: string; } // When actually implementing the component: interface ItemProps { color?: string; children?: React.ReactNode; }
1-38: Consider adding consistent default values information.Both props have default values listed as "--" which implies they don't have default values. If the
colorprop has a default value in the actual implementation, it would be helpful to document it here. Similarly, clarify ifchildrencan be null/undefined.For example, if color has a default value:
- default : "--", + default : "gray", // or whatever the actual default is
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
docs/app/docs/components/avatar-group/docs/api/avatar.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/api/fallback.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/api/item.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/api/root.tsx(1 hunks)docs/app/docs/components/avatar/docs/api/root.tsx(1 hunks)docs/app/docs/components/callout/docs/api/root.tsx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- docs/app/docs/components/avatar-group/docs/api/root.tsx
- docs/app/docs/components/avatar/docs/api/root.tsx
- docs/app/docs/components/avatar-group/docs/api/fallback.tsx
- docs/app/docs/components/callout/docs/api/root.tsx
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
docs/app/docs/components/avatar/docs/codeUsage.js (1)
28-40: Consider removing or updating the legacy example objectThe
avatarBasicUsageExampleobject seems redundant now that you've introduced the more structuredapi_documentationexport. This object appears to contain outdated documentation that doesn't reflect the new composable API structure with separate Root, Image, and Fallback components.Consider either:
- Removing this object if it's no longer used
- Updating it to align with the new component structure
- Adding a comment explaining why it's being retained if needed for backward compatibility
docs/app/docs/components/callout/docs/codeUsage.js (1)
4-4: Import style inconsistency.There's an inconsistency in import styles -
icon_api_SourceCodeuses named import syntax with curly braces while the other imports use default import syntax. Consider standardizing the import approach for better consistency.-import {icon_api_SourceCode} from './component_api/icon.tsx'; +import icon_api_SourceCode from './component_api/icon.tsx';docs/app/docs/components/toggle-group/docs/codeUsage.js (1)
1-27: Consider standardizing variable naming conventions.The variable names use slightly inconsistent patterns:
example_1_SourceCode,scss_SourceCode, androot_api_SourceCode. Consider standardizing the naming pattern across all variables for better readability.-const example_1_SourceCode = await getSourceCodeFromPath('docs/app/docs/components/toggle-group/docs/examples/ToggleGroupExample.tsx'); -const scss_SourceCode = await getSourceCodeFromPath('styles/themes/components/toggle-group.scss'); -import root_api_SourceCode from "./component_api/root.tsx"; -import item_api_SourceCode from "./component_api/item.tsx"; +const exampleSourceCode = await getSourceCodeFromPath('docs/app/docs/components/toggle-group/docs/examples/ToggleGroupExample.tsx'); +const scssSourceCode = await getSourceCodeFromPath('styles/themes/components/toggle-group.scss'); +import rootApiSourceCode from "./component_api/root.tsx"; +import itemApiSourceCode from "./component_api/item.tsx"; export const api_documentation = { - root: root_api_SourceCode, - item: item_api_SourceCode + root: rootApiSourceCode, + item: itemApiSourceCode }; const code = { javascript: { - code: example_1_SourceCode, + code: exampleSourceCode, }, css: { - code: scss_SourceCode + code: scssSourceCode } };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (34)
docs/app/docs/components/accordion/docs/codeUsage.js(1 hunks)docs/app/docs/components/avatar-group/docs/codeUsage.js(2 hunks)docs/app/docs/components/avatar-group/docs/component_api/avatar.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/component_api/fallback.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/component_api/item.tsx(1 hunks)docs/app/docs/components/avatar-group/docs/component_api/root.tsx(1 hunks)docs/app/docs/components/avatar/docs/codeUsage.js(1 hunks)docs/app/docs/components/avatar/docs/component_api/fallback.tsx(1 hunks)docs/app/docs/components/avatar/docs/component_api/image.tsx(1 hunks)docs/app/docs/components/avatar/docs/component_api/root.tsx(1 hunks)docs/app/docs/components/blockquote/docs/codeUsage.js(1 hunks)docs/app/docs/components/button/docs/codeUsage.js(1 hunks)docs/app/docs/components/callout/docs/codeUsage.js(1 hunks)docs/app/docs/components/callout/docs/component_api/icon.tsx(1 hunks)docs/app/docs/components/callout/docs/component_api/root.tsx(1 hunks)docs/app/docs/components/callout/docs/component_api/text.tsx(1 hunks)docs/app/docs/components/card/docs/codeUsage.js(1 hunks)docs/app/docs/components/code/docs/codeUsage.js(1 hunks)docs/app/docs/components/em/docs/codeUsage.js(1 hunks)docs/app/docs/components/heading/docs/codeUsage.js(1 hunks)docs/app/docs/components/kbd/docs/codeUsage.js(1 hunks)docs/app/docs/components/progress/docs/codeUsage.js(1 hunks)docs/app/docs/components/progress/docs/component_api/indicator.tsx(1 hunks)docs/app/docs/components/progress/docs/component_api/root.tsx(1 hunks)docs/app/docs/components/separator/docs/codeUsage.js(1 hunks)docs/app/docs/components/strong/docs/codeUsage.js(1 hunks)docs/app/docs/components/switch/docs/codeUsage.js(1 hunks)docs/app/docs/components/switch/docs/component_api/root.tsx(1 hunks)docs/app/docs/components/switch/docs/component_api/thumb.tsx(1 hunks)docs/app/docs/components/text/docs/codeUsage.js(1 hunks)docs/app/docs/components/toggle-group/docs/codeUsage.js(1 hunks)docs/app/docs/components/toggle-group/docs/component_api/item.tsx(1 hunks)docs/app/docs/components/toggle-group/docs/component_api/root.tsx(1 hunks)docs/app/docs/components/tooltip/docs/codeUsage.js(1 hunks)
✅ Files skipped from review due to trivial changes (27)
- docs/app/docs/components/strong/docs/codeUsage.js
- docs/app/docs/components/button/docs/codeUsage.js
- docs/app/docs/components/separator/docs/codeUsage.js
- docs/app/docs/components/code/docs/codeUsage.js
- docs/app/docs/components/kbd/docs/codeUsage.js
- docs/app/docs/components/heading/docs/codeUsage.js
- docs/app/docs/components/card/docs/codeUsage.js
- docs/app/docs/components/em/docs/codeUsage.js
- docs/app/docs/components/text/docs/codeUsage.js
- docs/app/docs/components/tooltip/docs/codeUsage.js
- docs/app/docs/components/progress/docs/component_api/root.tsx
- docs/app/docs/components/avatar/docs/component_api/image.tsx
- docs/app/docs/components/accordion/docs/codeUsage.js
- docs/app/docs/components/avatar/docs/component_api/fallback.tsx
- docs/app/docs/components/switch/docs/component_api/thumb.tsx
- docs/app/docs/components/avatar-group/docs/component_api/fallback.tsx
- docs/app/docs/components/progress/docs/component_api/indicator.tsx
- docs/app/docs/components/avatar-group/docs/component_api/item.tsx
- docs/app/docs/components/toggle-group/docs/component_api/item.tsx
- docs/app/docs/components/switch/docs/component_api/root.tsx
- docs/app/docs/components/avatar-group/docs/component_api/avatar.tsx
- docs/app/docs/components/toggle-group/docs/component_api/root.tsx
- docs/app/docs/components/callout/docs/component_api/text.tsx
- docs/app/docs/components/avatar/docs/component_api/root.tsx
- docs/app/docs/components/avatar-group/docs/component_api/root.tsx
- docs/app/docs/components/callout/docs/component_api/icon.tsx
- docs/app/docs/components/callout/docs/component_api/root.tsx
🚧 Files skipped from review as they are similar to previous changes (4)
- docs/app/docs/components/avatar-group/docs/codeUsage.js
- docs/app/docs/components/blockquote/docs/codeUsage.js
- docs/app/docs/components/progress/docs/codeUsage.js
- docs/app/docs/components/switch/docs/codeUsage.js
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
🔇 Additional comments (13)
docs/app/docs/components/avatar/docs/codeUsage.js (4)
1-5: Good improvement using external source files!Moving from hardcoded code strings to dynamically loaded source code using
getSourceCodeFromPathis a great practice that improves maintainability and separation of concerns. This approach makes the example code and styles more maintainable as they can be edited in their own files with proper syntax highlighting and validation.
8-10: Well-structured API documentation importsBreaking down the API documentation into separate files for each subcomponent (Root, Image, Fallback) follows good modular design principles. This supports the composable API pattern and makes the documentation more focused and maintainable.
14-15: Consistent usage of external source filesThe code and SCSS references now use the dynamically loaded source code, which is consistent with the changes made in lines 1-5.
Also applies to: 17-18
22-26: Good addition of structured API documentation exportThe new
api_documentationexport provides a well-organized way to access documentation for each Avatar subcomponent. This structure supports the composable API pattern and will help generate clear, component-specific documentation tables.docs/app/docs/components/callout/docs/codeUsage.js (4)
1-1: Improved modular API documentation structure.The imports have been restructured to support a composable API pattern with separate documentation for root, icon, and text components. This aligns with the broader pattern of modularization across UI components mentioned in the PR summary.
Also applies to: 3-5
8-10: Good refactoring to external source files.The change from hardcoded example strings to dynamically loaded external source code is a good practice that improves maintainability and separation of concerns.
Note that the use of top-level
awaitrequires Node.js 14.8+ or an environment that supports ES modules with top-level await.
13-13: Successfully updated references to dynamically loaded code.The code object now properly references the dynamically loaded source code instead of hardcoded strings, which aligns with the external source loading approach.
Also applies to: 16-16
24-26: Comprehensive API documentation with composable pattern.The API documentation now follows a composable pattern with separate entries for root, icon, and text components, which makes the documentation more organized and easier to navigate.
docs/app/docs/components/toggle-group/docs/codeUsage.js (5)
1-3: Well-structured approach to loading example code.Importing source code from external files rather than defining it inline creates better separation of concerns and makes both the documentation and examples easier to maintain.
5-6: Good separation of styling from documentation code.Importing SCSS code externally keeps the documentation file clean and focused on structure rather than implementation details.
8-9: Excellent modular API documentation approach.Importing API details from dedicated files per component part (root and item) aligns with the composable API structure and improves maintainability.
12-15: Clear organization of composable component API.The exported object structure explicitly documents the composable nature of the ToggleGroup component, making it clear to users that it consists of root and item subcomponents.
17-24: Consistent code example structure.The code object follows a clean pattern for organizing example source code, making it easy for documentation rendering components to access this content.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
docs/app/docs/components/callout/page.mdx (2)
6-6: Remove UnusedBookmarkIconImport
After migrating the example intoCalloutExample,BookmarkIconis no longer referenced in this file. Consider removing it to avoid unused imports.
1-1: Remove or UsePageDetailsImport
PageDetailsis imported but never used. Either remove this import or render<PageDetails {...metadata} />if it’s intended to inject SEO metadata.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
docs/app/docs/components/callout/docs/codeUsage.js(1 hunks)docs/app/docs/components/callout/docs/component_api/callout_icon.tsx(1 hunks)docs/app/docs/components/callout/page.mdx(3 hunks)
✅ Files skipped from review due to trivial changes (1)
- docs/app/docs/components/callout/docs/component_api/callout_icon.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/app/docs/components/callout/docs/codeUsage.js
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
🔇 Additional comments (2)
docs/app/docs/components/callout/page.mdx (2)
5-5: Import New Composable Example Component
The import ofCalloutExamplealigns with the composable API pattern and matches existing example imports.
23-23: Use ComposableCalloutExample
Replacing the inline Callout with<CalloutExample />properly delegates the example rendering to the external component.
| {/* API Documentation */} | ||
| <Documentation.Table title="Root" description={api_documentation.root.description} columns={api_documentation.root.columns} data={api_documentation.root.data} /> | ||
| <Documentation.Table title="Icon" description={api_documentation.root.description} columns={api_documentation.root.columns} data={api_documentation.root.data} /> | ||
| <Documentation.Table title="Text" description={api_documentation.text.description} columns={api_documentation.text.columns} data={api_documentation.text.data} /> */} |
There was a problem hiding this comment.
Fix Comment Wrapping and API Table Data
The current comment syntax is invalid (you open a comment on line 47 but only close it on the last table line), and the Icon table is wired to api_documentation.root instead of api_documentation.icon. This will cause MDX parsing errors and incorrect docs if uncommented. Please update as follows:
-{/* API Documentation */}
-<Documentation.Table title="Root" description={api_documentation.root.description} columns={api_documentation.root.columns} data={api_documentation.root.data} />
-<Documentation.Table title="Icon" description={api_documentation.root.description} columns={api_documentation.root.columns} data={api_documentation.root.data} />
-<Documentation.Table title="Text" description={api_documentation.text.description} columns={api_documentation.text.columns} data={api_documentation.text.data} /> */}
+{/*
+ {/* API Documentation */}
+ <Documentation.Table
+ title="Root"
+ description={api_documentation.root.description}
+ columns={api_documentation.root.columns}
+ data={api_documentation.root.data}
+ />
+ <Documentation.Table
+ title="Icon"
+ description={api_documentation.icon.description}
+ columns={api_documentation.icon.columns}
+ data={api_documentation.icon.data}
+ />
+ <Documentation.Table
+ title="Text"
+ description={api_documentation.text.description}
+ columns={api_documentation.text.columns}
+ data={api_documentation.text.data}
+ />
+*/}📝 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.
| {/* API Documentation */} | |
| <Documentation.Table title="Root" description={api_documentation.root.description} columns={api_documentation.root.columns} data={api_documentation.root.data} /> | |
| <Documentation.Table title="Icon" description={api_documentation.root.description} columns={api_documentation.root.columns} data={api_documentation.root.data} /> | |
| <Documentation.Table title="Text" description={api_documentation.text.description} columns={api_documentation.text.columns} data={api_documentation.text.data} /> */} | |
| {/* | |
| {/* API Documentation */} | |
| <Documentation.Table | |
| title="Root" | |
| description={api_documentation.root.description} | |
| columns={api_documentation.root.columns} | |
| data={api_documentation.root.data} | |
| /> | |
| <Documentation.Table | |
| title="Icon" | |
| description={api_documentation.icon.description} | |
| columns={api_documentation.icon.columns} | |
| data={api_documentation.icon.data} | |
| /> | |
| <Documentation.Table | |
| title="Text" | |
| description={api_documentation.text.description} | |
| columns={api_documentation.text.columns} | |
| data={api_documentation.text.data} | |
| /> | |
| */} |
Summary by CodeRabbit
New Features
Refactor
Documentation
Style
Chores