chore: button migration #2739
chore: button migration #2739
Conversation
chronark
requested review from
perkinsjr,
mcstepp,
ogzhanolguncu and
MichaelUnkey
as code owners
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
📝 WalkthroughWalkthroughThe pull request includes significant updates to the dependency management in the Changes
Possibly related PRs
Suggested labels
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 (
|
|
Thank you for following the naming conventions for pull request titles! 🙏 |
![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 (22)
apps/dashboard/app/(app)/logs/components/log-details/components/log-meta.tsx (1)
Line range hint
25-32: LGTM! Consider enhancing error handlingThe Button implementation is well-structured with proper accessibility and styling. The shape="square" prop is appropriate for this icon-only button context.
Consider adding more specific error handling for the clipboard operation:
const handleClick = () => { navigator.clipboard .writeText(content) .then(() => { toast.success("Meta copied to clipboard"); }) .catch((error) => { - console.error("Failed to copy to clipboard:", error); - toast.error("Failed to copy to clipboard"); + console.error("Clipboard operation failed:", error); + toast.error( + error instanceof Error + ? `Failed to copy: ${error.message}` + : "Failed to copy to clipboard" + ); }); };apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-owner-id.tsx (1)
Based on the search results, I can see a clear pattern in the codebase for save buttons, particularly in settings pages. Looking at similar files in the settings sections (like
update-user-name.tsxandupdate-user-email.tsx), save buttons consistently use thevariant="primary"prop. However, in the file under review (update-key-owner-id.tsx), the Button is missing this variant prop.Add
variant="primary"to maintain consistent stylingThe save button should include the primary variant to match the styling pattern used across the dashboard's settings pages:
<Button disabled={updateOwnerId.isLoading || !form.formState.isValid} type="submit" variant="primary">🔗 Analysis chain
Line range hint
94-96: Verify button styling after migrationThe Button implementation looks correct, but since the AI summary mentions removal of size and variant attributes, please verify that the default styling from @unkey/ui matches the expected appearance for this save button.
Let's check for any style-related regressions:
Based on the search results, I can see that buttons throughout the codebase consistently use variants like "primary", "destructive", "ghost", "default", and "outline". The button in the file under review doesn't specify any variant, which could lead to styling inconsistencies.
Let me verify if there are any specific button styling patterns in the dashboard app by searching for similar save buttons:
Let me try a different search pattern to find save buttons:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Look for previous button styling patterns # to ensure consistent appearance after migration # Search for previous button styling patterns rg -B 2 -A 2 '<Button.*?(size|variant)=' # Look for any custom button styles that might need adjustment rg 'Button.*?className='Length of output: 35770
Script:
#!/bin/bash # Look for save buttons in dashboard app to verify consistent styling rg -B 2 -A 2 '<Button.*?>\s*(?:Save|{.*?Save.*?})' apps/dashboard/Length of output: 201
Script:
#!/bin/bash # Look for save buttons in dashboard app to verify consistent styling rg -B 2 -A 2 '"Save"' apps/dashboard/ # Also search for Button components with primary variant in settings pages rg -B 2 -A 2 'variant="primary".*Save' apps/dashboard/app/\(app\)/settings/Length of output: 10691
apps/dashboard/app/(app)/ratelimits/[namespaceId]/settings/delete-namespace.tsx (1)
166-169: Consider adding aria-label for better accessibilityWhile the button implementation is correct, consider adding an aria-label to provide more context for screen readers, especially during the loading state.
<Button type="submit" variant="destructive" + aria-label={deleteNamespace.isLoading ? "Deleting namespace..." : "Confirm namespace deletion"} disabled={!isValid || deleteNamespace.isLoading} > {deleteNamespace.isLoading ? <Loading /> : "Delete namespace"} </Button>apps/dashboard/app/(app)/semantic-cache/[gatewayId]/settings/delete-gateway.tsx (1)
Line range hint
168-172: Consider adding a confirmation tooltipThe variant change to "destructive" is appropriate. While the current implementation already has a good confirmation flow, consider adding a tooltip to the disabled state to guide users on what they need to do to enable the button.
<Button type="submit" variant="destructive" disabled={!isValid || deleteGateway.isLoading} + title={!isValid ? "Please confirm the gateway name and intent" : ""} > {deleteGateway.isLoading ? <Loading /> : "Delete gateway"} </Button>apps/dashboard/components/dashboard/create-key-button.tsx (2)
6-6: Remove outdated commentThe comment "Add missing import" appears to be outdated as all required imports are present.
Button variant should be updated to "default"
The codebase shows inconsistent usage of Button variants. While most files in the dashboard app use
variant="default"orvariant="ghost", the create-key-button.tsx usesvariant="primary". This should be updated to maintain consistency with the rest of the application.
apps/dashboard/components/dashboard/create-key-button.tsx: Update both instances ofvariant="primary"tovariant="default"🔗 Analysis chain
Line range hint
16-24: Verify Button variant propertyThe Button components use
variant="primary"which might need to be updated to match @unkey/ui's API. Other files in this PR usevariant="default".🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for all Button variant usages in the codebase to verify consistency rg -A 1 'Button.*variant=' --type tsxLength of output: 67
Script:
#!/bin/bash # Search for all Button variant usages in the codebase, including both tsx and ts files rg -A 1 'Button.*variant='Length of output: 14531
apps/dashboard/components/dashboard/confirm.tsx (1)
44-44: Review border styling for destructive variantThe border styling is conditionally applied based on the destructive variant. Consider extracting this styling to a consistent theme configuration.
-className={cn("sm:max-w-[425px]", { "border-alert": props.variant === "destructive" })} +className={cn("sm:max-w-[425px]", { "border-destructive": props.variant === "destructive" })}apps/dashboard/app/(app)/mobile-sidebar.tsx (1)
Line range hint
18-18: Consider documenting button variant standardsWhile the button migration is progressing well, consider documenting standard variant usage patterns:
- "primary" for form submissions
- "ghost" for navigation items
This will help maintain consistency as the migration continues.Also applies to: 8-8, 18-18
apps/dashboard/app/(app)/settings/general/update-workspace-name.tsx (1)
1-1: Consider a comprehensive UI component migration strategyThe current PR only migrates the Button component, but there are still many UI components from the local library (Loading, Input, Form, etc.). Consider:
- Creating a migration plan for all UI components to @unkey/ui
- Establishing clear documentation for supported variants and props
- Adding CI checks to prevent usage of deprecated local UI components
- Creating codemods to automate future migrations
apps/dashboard/app/(app)/authorization/permissions/[permissionId]/client.tsx (1)
Line range hint
16-17: Consider documenting button migration guidelinesTo ensure consistency across the codebase during this button migration:
- Document supported variants in @unkey/ui
- Create a migration checklist for handling props like variant, size, etc.
- Consider adding ESLint rules to prevent usage of the old button import path
Also applies to: 66-71, 93-98
apps/dashboard/app/(app)/authorization/permissions/[permissionId]/delete-permission.tsx (2)
26-26: Consistent implementation with delete-role.tsxThe changes mirror those in delete-role.tsx, which is good for consistency. However, the button text was simplified to just "Delete" while delete-role.tsx uses "Delete Role".
Consider using consistent button text format:
- Delete + Delete PermissionAlso applies to: 122-126
Line range hint
19-26: Well-structured button component migrationThe migration to @unkey/ui shows good architectural decisions:
- Consistent import changes across files
- Standardized handling of destructive actions
- Improved loading state feedback
- Maintained form validation integration
This standardization will improve maintainability and user experience consistency.
apps/dashboard/app/new/create-api.tsx (1)
19-19: LGTM! Consider extracting loading text to a constant.The Button migration looks good. The variant has been simplified to "primary" while maintaining form validation and loading state handling.
Consider extracting the loading text to a constant for better maintainability:
+const BUTTON_TEXT = { + loading: "Creating API...", + default: "Create API" +} as const; <Button variant="primary" disabled={createApi.isLoading || !form.formState.isValid} type="submit" className="w-full" > - {createApi.isLoading ? <Loading /> : "Create API"} + {createApi.isLoading ? <Loading /> : BUTTON_TEXT.default} </Button>Also applies to: 19-19, 107-113
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-expiration.tsx (1)
Line range hint
7-7: Consider documenting button variant conventionsThe migration to
@unkey/uiintroduces consistent patterns for button variants:
- Destructive variant for delete actions
- Default variant for save actions
- Simplified variant usage for edit actions
Consider documenting these conventions in your UI guidelines to maintain consistency as the application grows.
Also applies to: 12-12, 26-26
apps/dashboard/app/(app)/ratelimits/[namespaceId]/overrides/[overrideId]/settings.tsx (1)
24-24: Consider explicit variant for delete buttonThe delete button no longer has an explicit variant, while being placed next to a primary action (save). This might affect the visual hierarchy of actions.
Consider adding an appropriate variant to maintain clear action hierarchy:
-<Button type="button" onClick={() => deleteOverride.mutate({ id: overrideId })}> +<Button type="button" variant="destructive" onClick={() => deleteOverride.mutate({ id: overrideId })}>Also applies to: 165-169
apps/dashboard/app/(app)/apis/[apiId]/settings/delete-protection.tsx (1)
Line range hint
159-161: Fix typo in descriptionThere's a typo in the card description: "disabeled" should be "disabled"
-Delete protection is currently disabeled. You can enable it to prevent this API from +Delete protection is currently disabled. You can enable it to prevent this API fromapps/dashboard/app/(app)/authorization/roles/create-new-role.tsx (1)
Consider adding shape="square" to form submission button
Based on the codebase analysis, I found that:
- Many buttons in the codebase use the
shape="square"property, particularly in similar UI contexts- The form submission button in the create-new-role component currently doesn't specify any shape property
- For visual consistency with other square-shaped buttons in the dashboard, this button should also use
shape="square"Example locations where square-shaped buttons are used:
apps/dashboard/app/(app)/settings/vercel/client.tsxapps/dashboard/app/(app)/ratelimits/[namespaceId]/logs/menu.tsxapps/dashboard/components/array-input.tsx🔗 Analysis chain
Line range hint
165-167: Consider adding shape property to form submission buttonBased on the migration pattern seen in other files, consider whether this button should have specific shape/variant properties for consistency.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for similar form submission buttons to verify consistent properties rg -A 2 -B 2 'Button.*type="submit"' --type tsxLength of output: 77
Script:
#!/bin/bash # Search for Button components with type="submit" in all files rg -A 2 -B 2 'Button.*type="submit"'Length of output: 13507
Script:
#!/bin/bash # Search for form submission buttons with shape/variant properties rg -A 2 -B 2 'Button.*shape.*type="submit"'Length of output: 45
Script:
#!/bin/bash # Search for Button components with shape property rg 'Button.*shape='Length of output: 1399
apps/dashboard/app/(app)/logs/components/filters/components/search-combobox/search-combobox.tsx (1)
Custom hover styles may cause inconsistencies with Button component
The
hover:bg-current!andhover:text-current!styles are not part of the standard styling patterns used in the @unkey/ui Button component, as seen in its implementation. The Button component uses predefined variants with specific hover states:
- Default variant uses
hover:bg-gray-4- Primary variant uses
hover:bg-gray-1- Ghost variant uses
hover:bg-gray-3Using
!importantmodifiers (!) withcurrentcolor values could override these carefully designed hover states and potentially break the visual consistency of the component.Recommendations:
- Remove the custom hover styles and use the Button's built-in variants
- If a custom appearance is needed, consider using the
ghostvariant which provides minimal styling and is more suitable for trigger buttons🔗 Analysis chain
Line range hint
93-98: Verify custom styling compatibilityThe Button component uses custom hover styles and serves as a PopoverTrigger. Please verify that:
- The hover:bg-current! and hover:text-current! styles work as expected with @unkey/ui
- The button maintains its proper appearance when used as a trigger
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for similar button usage patterns to ensure consistent styling rg 'hover:bg-current!' --type tsx rg 'PopoverTrigger.*Button' --type tsxLength of output: 132
Script:
#!/bin/bash # Search for similar button usage patterns to ensure consistent styling, using correct file extensions rg 'hover:bg-current!' -t ts -t tsx -t jsx rg 'PopoverTrigger.*Button' -t ts -t tsx -t jsx # Look for the specific component file fd -e tsx -e ts -e jsx "search-combobox.tsx$" # If we find the file, let's examine its content fd -e tsx -e ts -e jsx "search-combobox.tsx$" -x cat {}Length of output: 6242
Script:
#!/bin/bash # Let's check the Button component from @unkey/ui to understand its styling system fd -g "button.tsx" -x cat {} # Let's also check for any other similar Popover + Button combinations in the codebase rg -B 2 -A 2 "PopoverTrigger.*asChild.*Button" . # Check for any similar hover style patterns in the codebase rg "hover:(bg|text)-" .Length of output: 37369
apps/dashboard/components/dashboard/feedback-component.tsx (1)
Line range hint
156-166: Consider using the loading prop for consistencyThe loading state is currently handled via conditional rendering of content. Consider using the new
loadingprop for consistency with other components in the codebase.<Button type="submit" disabled={create.isLoading} + loading={create.isLoading} onClick={form.handleSubmit((data) => { create.mutate(data); })} > - {create.isLoading ? <Loading /> : "Send"} + Send </Button>apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/chart.tsx (1)
209-210: Consider adding shape="square" for consistencyOther similar button instances in this file use shape="square". Consider adding it here for consistency.
- <Button variant="ghost"> + <Button variant="ghost" shape="square">apps/dashboard/app/(app)/settings/billing/page.tsx (1)
160-165: Consider maintaining visual hierarchy with button variantsThe removal of button variants from these navigation buttons might affect the visual hierarchy. Consider whether these actions should have different visual weights to guide user interaction.
- <Button className="whitespace-nowrap"> + <Button variant="secondary" className="whitespace-nowrap"> {paymentMethod ? "Update Card" : "Add Credit Card"} </Button> </Link> <Link href="/settings/billing/plans"> - <Button className="whitespace-nowrap"> + <Button variant="primary" className="whitespace-nowrap">apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/new/client.tsx (1)
201-204: Consider maintaining visual hierarchy with button variantsThe removal of button variants from these navigation buttons ("Back" and "View key details") might affect the visual hierarchy. Consider whether these actions should have different visual weights to guide user interaction.
- <Button>Back</Button> + <Button variant="secondary">Back</Button> </Link> <Link href={`/apis/${apiId}/keys/${keyAuthId}/${key.data.keyId}`}> - <Button>View key details</Button> + <Button variant="primary">View key details</Button>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (82)
apps/agent/go.mod(0 hunks)apps/dashboard/app/(app)/[...not-found]/page.tsx(2 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/chart.tsx(4 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/page.tsx(3 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/delete-key.tsx(3 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-enabled.tsx(1 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-expiration.tsx(1 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-metadata.tsx(1 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-name.tsx(1 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-owner-id.tsx(1 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-ratelimit.tsx(1 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-remaining.tsx(1 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/keys.tsx(1 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/new/client.tsx(2 hunks)apps/dashboard/app/(app)/apis/[apiId]/settings/default-bytes.tsx(2 hunks)apps/dashboard/app/(app)/apis/[apiId]/settings/default-prefix.tsx(2 hunks)apps/dashboard/app/(app)/apis/[apiId]/settings/delete-api.tsx(3 hunks)apps/dashboard/app/(app)/apis/[apiId]/settings/delete-protection.tsx(4 hunks)apps/dashboard/app/(app)/apis/[apiId]/settings/update-api-name.tsx(2 hunks)apps/dashboard/app/(app)/apis/[apiId]/settings/update-ip-whitelist.tsx(2 hunks)apps/dashboard/app/(app)/audit/[bucket]/filter.tsx(2 hunks)apps/dashboard/app/(app)/audit/[bucket]/page.tsx(4 hunks)apps/dashboard/app/(app)/authorization/permissions/[permissionId]/client.tsx(1 hunks)apps/dashboard/app/(app)/authorization/permissions/[permissionId]/delete-permission.tsx(2 hunks)apps/dashboard/app/(app)/authorization/permissions/[permissionId]/page.tsx(2 hunks)apps/dashboard/app/(app)/authorization/permissions/create-new-permission.tsx(1 hunks)apps/dashboard/app/(app)/authorization/permissions/page.tsx(1 hunks)apps/dashboard/app/(app)/authorization/roles/[roleId]/delete-role.tsx(2 hunks)apps/dashboard/app/(app)/authorization/roles/[roleId]/page.tsx(2 hunks)apps/dashboard/app/(app)/authorization/roles/[roleId]/update-role.tsx(1 hunks)apps/dashboard/app/(app)/authorization/roles/create-new-role.tsx(1 hunks)apps/dashboard/app/(app)/authorization/roles/page.tsx(1 hunks)apps/dashboard/app/(app)/identities/[identityId]/page.tsx(2 hunks)apps/dashboard/app/(app)/logs/components/filters/components/custom-date-filter.tsx(2 hunks)apps/dashboard/app/(app)/logs/components/filters/components/search-combobox/badge.tsx(2 hunks)apps/dashboard/app/(app)/logs/components/filters/components/search-combobox/search-combobox.tsx(1 hunks)apps/dashboard/app/(app)/logs/components/filters/index.tsx(2 hunks)apps/dashboard/app/(app)/logs/components/log-details/components/log-header.tsx(2 hunks)apps/dashboard/app/(app)/logs/components/log-details/components/log-meta.tsx(2 hunks)apps/dashboard/app/(app)/logs/components/log-details/components/log-section.tsx(2 hunks)apps/dashboard/app/(app)/mobile-sidebar.tsx(1 hunks)apps/dashboard/app/(app)/ratelimits/[namespaceId]/filters.tsx(2 hunks)apps/dashboard/app/(app)/ratelimits/[namespaceId]/logs/filter.tsx(8 hunks)apps/dashboard/app/(app)/ratelimits/[namespaceId]/logs/menu.tsx(2 hunks)apps/dashboard/app/(app)/ratelimits/[namespaceId]/overrides/[overrideId]/settings.tsx(2 hunks)apps/dashboard/app/(app)/ratelimits/[namespaceId]/overrides/create-new-override.tsx(1 hunks)apps/dashboard/app/(app)/ratelimits/[namespaceId]/overrides/table.tsx(1 hunks)apps/dashboard/app/(app)/ratelimits/[namespaceId]/settings/delete-namespace.tsx(3 hunks)apps/dashboard/app/(app)/ratelimits/[namespaceId]/settings/update-namespace-name.tsx(2 hunks)apps/dashboard/app/(app)/ratelimits/create-namespace-button.tsx(1 hunks)apps/dashboard/app/(app)/ratelimits/page.tsx(2 hunks)apps/dashboard/app/(app)/semantic-cache/[gatewayId]/settings/delete-gateway.tsx(3 hunks)apps/dashboard/app/(app)/settings/billing/page.tsx(2 hunks)apps/dashboard/app/(app)/settings/billing/plans/button.tsx(3 hunks)apps/dashboard/app/(app)/settings/billing/plans/page.tsx(2 hunks)apps/dashboard/app/(app)/settings/general/update-workspace-name.tsx(2 hunks)apps/dashboard/app/(app)/settings/root-keys/[keyId]/page.tsx(2 hunks)apps/dashboard/app/(app)/settings/root-keys/[keyId]/permissions/legacy.tsx(2 hunks)apps/dashboard/app/(app)/settings/root-keys/[keyId]/permissions/permission-manager-card.tsx(2 hunks)apps/dashboard/app/(app)/settings/root-keys/[keyId]/update-root-key-name.tsx(1 hunks)apps/dashboard/app/(app)/settings/root-keys/new/client.tsx(1 hunks)apps/dashboard/app/(app)/settings/root-keys/page.tsx(1 hunks)apps/dashboard/app/(app)/settings/team/invite.tsx(2 hunks)apps/dashboard/app/(app)/settings/team/page.tsx(3 hunks)apps/dashboard/app/(app)/settings/user/update-user-email.tsx(4 hunks)apps/dashboard/app/(app)/settings/user/update-user-name.tsx(2 hunks)apps/dashboard/app/(app)/settings/vercel/client.tsx(5 hunks)apps/dashboard/app/(app)/settings/vercel/page.tsx(1 hunks)apps/dashboard/app/integrations/vercel/callback/client.tsx(3 hunks)apps/dashboard/app/new/create-api.tsx(2 hunks)apps/dashboard/app/new/create-ratelimit.tsx(1 hunks)apps/dashboard/app/new/create-workspace.tsx(2 hunks)apps/dashboard/app/new/keys.tsx(3 hunks)apps/dashboard/app/new/page.tsx(1 hunks)apps/dashboard/app/ratelimit/page.tsx(1 hunks)apps/dashboard/components/array-input.tsx(2 hunks)apps/dashboard/components/dashboard/api-key-table/index.tsx(2 hunks)apps/dashboard/components/dashboard/api-key-table/table.tsx(4 hunks)apps/dashboard/components/dashboard/confirm.tsx(3 hunks)apps/dashboard/components/dashboard/create-key-button.tsx(1 hunks)apps/dashboard/components/dashboard/feedback-component.tsx(1 hunks)apps/dashboard/components/dashboard/root-key-table/index.tsx(2 hunks)
⛔ Files not processed due to max files limit (18)
- apps/dashboard/components/dashboard/root-key-table/table.tsx
- apps/dashboard/components/data-table/column-header.tsx
- apps/dashboard/components/data-table/faceted-filter.tsx
- apps/dashboard/components/data-table/pagination.tsx
- apps/dashboard/components/data-table/view-options.tsx
- apps/dashboard/components/opt-in.tsx
- apps/dashboard/components/ui/alert-dialog.tsx
- apps/dashboard/components/ui/back-button.tsx
- apps/dashboard/components/ui/button.tsx
- apps/dashboard/components/ui/calendar.tsx
- apps/dashboard/components/ui/group-button.tsx
- apps/dashboard/components/ui/pagination.tsx
- apps/engineering/content/design/components/button.icons.tsx
- apps/engineering/content/design/components/button.loading.tsx
- apps/engineering/content/design/components/button.mdx
- apps/engineering/content/design/components/button.shape.tsx
- apps/engineering/tailwind.config.js
- internal/ui/src/components/button.tsx
💤 Files with no reviewable changes (1)
- apps/agent/go.mod
🔇 Additional comments (107)
apps/dashboard/app/(app)/logs/components/filters/components/search-combobox/badge.tsx (2)
4-4: LGTM: Button import updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui, aligning with the PR's migration objectives.
Line range hint 118-124: Verify visual consistency after property change
The button property change from size="icon" to shape="square" looks correct, but let's verify that the visual appearance remains consistent with other similar buttons in the application.
✅ Verification successful
Visual consistency confirmed for square-shaped buttons with w-4 h-4 dimensions
The search results show consistent usage of w-4 h-4 dimensions across various icon buttons in the codebase, particularly in similar UI patterns like filters and menus. The remaining size="icon" instances are in a different app (www) and don't affect the dashboard's consistency.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other instances of square-shaped buttons to verify consistent styling
rg -l 'shape="square"' | xargs rg 'className=".*w-4.*h-4'
# Search for any remaining icon-sized buttons that might need migration
rg 'size="icon"'
Length of output: 3540
apps/dashboard/app/(app)/authorization/roles/[roleId]/page.tsx (2)
3-3: LGTM: Button import migration looks correct
The Button component import has been successfully migrated from the local UI library to @unkey/ui as intended.
120-121: Verify consistent button styling across similar actions
The button styling changes look appropriate:
- Default variant for update actions
- Destructive variant for delete actions
Let's verify this pattern is consistently applied across the codebase:
✅ Verification successful
Button styling is consistently applied across similar actions
The verification confirms consistent button styling patterns:
- Update actions use default variant (no variant prop) or ghost variant for secondary actions
- Delete actions consistently use the "destructive" variant across all instances
Examples found:
- Role management: Default variant for Update, destructive for Delete
- Permissions: Destructive variant for Delete
- API Keys: Ghost variant for Update (secondary action)
- Design system documentation confirms these patterns
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other update/delete button implementations to ensure consistent styling
echo "Checking Update buttons:"
rg -B 2 -A 2 '<Button[^>]*>Update' --type tsx
echo "Checking Delete buttons:"
rg -B 2 -A 2 '<Button[^>]*>Delete' --type tsx
Length of output: 269
Script:
#!/bin/bash
# Search for other update/delete button implementations to ensure consistent styling
echo "Checking Update buttons:"
rg -B 2 -A 2 '<Button[^>]*>Update'
echo "Checking Delete buttons:"
rg -B 2 -A 2 '<Button[^>]*>Delete'
Length of output: 4504
apps/dashboard/app/(app)/logs/components/log-details/components/log-meta.tsx (1)
3-3: Verify @unkey/ui package installation
The Button import has been changed to use @unkey/ui package. Let's ensure this dependency is properly configured.
✅ Verification successful
The shell script results show that the @unkey/ui package is properly configured in the workspace dependencies and is extensively used across the codebase. The Button component from @unkey/ui is imported in numerous files, including the file under review (log-meta.tsx), indicating this is a standard pattern in the codebase.
Import change to @unkey/ui is properly configured
The Button import change from local UI library to @unkey/ui is verified as a valid change that aligns with the codebase's patterns. The package is properly configured and widely used across the project.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify @unkey/ui package installation and version
# Check if package.json exists and contains @unkey/ui
fd -t f "package.json" -x jq -r '.dependencies["@unkey/ui"] // .devDependencies["@unkey/ui"] // empty'
# Check for any potential import issues across the codebase
rg -g '*.{ts,tsx,js,jsx}' '@unkey/ui' -C 2
Length of output: 56239
apps/dashboard/app/(app)/apis/[apiId]/settings/default-bytes.tsx (2)
16-16: LGTM: Import migration looks correct
The Button import has been successfully migrated from the local UI library to @unkey/ui as intended.
Line range hint 96-101: Verify Button API compatibility
The Button component is using the variant="primary" prop, but according to the AI summary, variant attributes were supposed to be removed in this migration.
Let's verify the supported props in the new @unkey/ui Button component:
apps/dashboard/app/(app)/apis/[apiId]/settings/update-ip-whitelist.tsx (2)
18-18: LGTM: Button import migration looks good
The import change from local UI library to @unkey/ui aligns with the PR objectives.
116-121: LGTM: Button properties updated correctly
The button changes align with the migration requirements:
- Static variant="primary"
- Loading state properly handled
- Clean and simplified content
Let's verify consistent button styling across similar forms:
✅ Verification successful
Button styling is consistent with design system patterns
Based on the codebase analysis, the button changes in the IP whitelist form align with the established patterns:
- Primary variant buttons are consistently used for form submissions across the application
- Loading states are properly handled using formState.isSubmitting
- Disabled states are consistently managed with form validation
- Button content follows the same pattern across similar forms
Key examples of consistent implementation:
apps/dashboard/app/(app)/settings/user/update-user-name.tsxapps/dashboard/app/(app)/settings/general/update-workspace-name.tsxapps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-name.tsx
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent button styling in form components
# Look for any remaining variant conditional logic or inconsistent button properties
# Search for Button components with variant props in form contexts
rg -A 3 'Button.*variant.*=.*' 'apps/dashboard/**/*.(tsx|jsx)'
# Search for similar form submission buttons to verify consistent patterns
ast-grep --pattern $'Button.*variant="primary".*\n.*disabled={.*isSubmitting.*}.*\n.*loading={.*isSubmitting.*}'
Length of output: 246
Script:
#!/bin/bash
# Let's try a more precise search without directory restrictions
# Search for Button components with variant props
rg -A 3 'Button.*variant.*=.*'
# Search for form submission buttons with loading states
rg -A 3 'Button.*loading.*=.*'
# Search for disabled buttons in forms
rg -A 3 'Button.*disabled.*=.*'
Length of output: 38077
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-owner-id.tsx (1)
18-18: LGTM: Button import migration looks correct
The Button import has been successfully migrated from the local UI library to @unkey/ui, which aligns with the PR objectives.
Let's verify that the Button component usage is compatible with the new @unkey/ui implementation:
✅ Verification successful
Based on the search results, I can see that the Button component is used extensively throughout the codebase with various props including disabled, type, variant, loading, shape, className, and others. Let me verify the specific usage in the file under review to ensure compatibility.
Let me try one more search to find the specific file and its Button usage since the previous path might have been incorrect.
Button import migration is compatible and correctly implemented
The Button component from @unkey/ui is used with standard props (disabled, type) that are commonly supported across React button implementations. The usage in this file matches the component's API as seen in other parts of the codebase, and the migration appears to be a straightforward replacement without any compatibility issues.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any Button props that might need migration
# Look for other Button usages to ensure consistent migration
# Search for Button props in the codebase
rg -A 2 '<Button.*?>'
# Search for the old button import to ensure complete migration
rg '@/components/ui/button'
Length of output: 44792
Script:
#!/bin/bash
# Check the specific Button usage in the file under review
rg -A 5 '<Button' 'apps/dashboard/app/\(app\)/apis/\[apiId\]/keys/\[keyAuthId\]/\[keyId\]/settings/update-key-owner-id.tsx'
# Check the Button component definition in @unkey/ui
ast-grep --pattern 'const Button = $$$'
Length of output: 4668
Script:
#!/bin/bash
# Find the correct file path first
fd "update-key-owner-id.tsx"
# Then check its content
rg -l "import.*Button.*from.*@unkey/ui" $(fd "update-key-owner-id.tsx")
rg -A 5 '<Button' $(fd "update-key-owner-id.tsx")
Length of output: 774
apps/dashboard/app/(app)/ratelimits/[namespaceId]/settings/delete-namespace.tsx (2)
96-98: LGTM! Improved semantic variant for destructive action
The button variant change from "alert" to "destructive" better represents the dangerous nature of the delete action, following common UI patterns.
2-2: Verify @unkey/ui dependency installation
The Button import has been updated to use @unkey/ui package as part of the button migration.
✅ Verification successful
Import change to @unkey/ui is correctly configured
The Button import from "@unkey/ui" is valid as the package is properly configured as a workspace dependency in the dashboard's package.json ("@unkey/ui": "workspace:^"). The package itself is located in the internal/ui directory and is correctly set up as a local workspace package.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the @unkey/ui package is properly listed in package.json
jq '.dependencies["@unkey/ui"]' package.json
Length of output: 51
Script:
#!/bin/bash
# Check if @unkey/ui is listed in devDependencies or other dependency fields
jq '.devDependencies["@unkey/ui"], .peerDependencies["@unkey/ui"]' package.json
# Check if there are workspace dependencies in the root package.json
jq '.workspaces' package.json
# If workspaces exist, let's check the UI package location
fd -t f "package.json" packages/ui/
Length of output: 288
Script:
#!/bin/bash
# Let's find all package.json files to locate the UI package
fd -t f "package.json$"
# Check if there are any references to @unkey/ui in the codebase
rg "@unkey/ui" -l
Length of output: 8270
Script:
#!/bin/bash
# Check the content of internal/ui/package.json to verify if it's the @unkey/ui package
cat internal/ui/package.json
# Check if there are any workspace dependencies in dashboard's package.json
cat apps/dashboard/package.json
Length of output: 5183
apps/dashboard/app/(app)/semantic-cache/[gatewayId]/settings/delete-gateway.tsx (1)
100-102: LGTM: Appropriate variant for destructive action
The button variant change from "alert" to "destructive" better represents the destructive nature of the action.
apps/dashboard/components/dashboard/create-key-button.tsx (1)
2-2: LGTM: Button import updated correctly
The Button import has been successfully migrated to @unkey/ui.
apps/dashboard/app/(app)/[...not-found]/page.tsx (1)
2-2: LGTM: Button migration completed correctly
The changes are consistent with the migration pattern:
- Import updated to @unkey/ui
- Variant property updated to "default"
Also applies to: 13-13
apps/dashboard/app/(app)/logs/components/log-details/components/log-header.tsx (1)
3-3: Verify Button property combination
The Button uses a new combination of properties (shape="square" variant="ghost"). While the migration from size="icon" to shape="square" is consistent with the new API, let's verify this combination pattern.
Also applies to: 32-32
✅ Verification successful
Button property combination is valid and commonly used
The combination of shape="square" variant="ghost" is a well-established pattern in the codebase, used consistently across multiple components for icon buttons, particularly with icons like MoreHorizontal, MoreVertical, ChevronRight, and X. This matches the usage in the log-header component.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for similar Button property combinations
rg 'Button.*shape="square".*variant="ghost"' --type tsx
rg 'Button.*variant="ghost".*shape="square"' --type tsx
Length of output: 171
Script:
#!/bin/bash
# Search for similar Button property combinations, using correct file extension
rg 'Button.*shape="square".*variant="ghost"' -g '*.ts*'
rg 'Button.*variant="ghost".*shape="square"' -g '*.ts*'
# Also search for general usage patterns of square shape
rg 'Button.*shape="square"' -g '*.ts*' -A 1
# And ghost variant usage
rg 'Button.*variant="ghost"' -g '*.ts*' -A 1
Length of output: 9501
apps/dashboard/app/(app)/settings/root-keys/page.tsx (1)
5-5: Verify Button variant support in @unkey/ui
The Button component is using variant="primary". Let's verify this variant is supported in the new @unkey/ui library.
Also applies to: 41-41
✅ Verification successful
Let me gather more information about the Button component definition since the previous search didn't find it.
Let me search specifically in the internal/ui directory since we found a reference to the Button component there.
Button component's "primary" variant is supported
The Button component from @unkey/ui fully supports the "primary" variant. The implementation in internal/ui/src/components/button.tsx explicitly defines the "primary" variant with appropriate styling.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other usages of primary variant with @unkey/ui Button
rg -l 'import.*Button.*@unkey/ui' | xargs rg 'variant="primary"'
# Search for Button component definition in the codebase
ast-grep --pattern 'export const Button = $$$'
Length of output: 7657
Script:
#!/bin/bash
# Search for Button component in @unkey/ui package
fd -e tsx -e ts "Button" packages/ui | xargs rg -l "variant.*=.*{" | xargs cat
# Alternative search for Button props or types
fd -e tsx -e ts "Button" packages/ui | xargs rg "type.*ButtonProps|interface.*Button"
Length of output: 1319
Script:
#!/bin/bash
# Check Button component definition and variants in internal UI
cat internal/ui/src/components/button.tsx
# Also check for any variant definitions
rg -A 5 "buttonVariants.*=.*{" internal/ui/src/components/button.tsx
Length of output: 4779
apps/dashboard/app/(app)/logs/components/filters/index.tsx (2)
39-52: Consistent button property migration needed
The Button properties have been updated inconsistently:
- Removed
variant="outline"from all buttons - Changed
size="icon"toshape="square"for the refresh button
3-3: Verify ButtonGroup compatibility with @unkey/ui Button
The ButtonGroup component from "@/components/ui/group-button" is being used with @unkey/ui Buttons. Let's ensure they are compatible.
Also applies to: 39-44, 47-49, 50-52
✅ Verification successful
Let me gather more information about the ButtonGroup usage with the new @unkey/ui Button to ensure compatibility.
Based on the gathered information, I can now generate the final response:
ButtonGroup is compatible with @unkey/ui Button
The ButtonGroup component from "@/components/ui/group-button" is designed to work with any Button component that accepts className prop for styling. The @unkey/ui Button component accepts className prop and follows standard button styling patterns, making it fully compatible with ButtonGroup's implementation which primarily manages layout and border styles through className modifications.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for ButtonGroup implementation
ast-grep --pattern 'export const ButtonGroup = $$$'
# Find other instances of ButtonGroup with @unkey/ui Button
rg -l 'import.*ButtonGroup.*@/components/ui/group-button' | xargs rg 'import.*Button.*@unkey/ui'
Length of output: 6568
Script:
#!/bin/bash
# Check ButtonGroup props interface
ast-grep --pattern 'interface ButtonGroupProps {
$$$
}'
# Find all files using ButtonGroup to see implementation patterns
rg -l 'ButtonGroup.*from.*group-button' | xargs rg -A 3 '<ButtonGroup'
# Check @unkey/ui Button implementation or types
rg -l '@unkey/ui.*Button' | xargs rg -A 5 'Button.*='
Length of output: 66189
apps/dashboard/components/dashboard/confirm.tsx (1)
12-12: Verify variant type change from "alert" to "destructive"
The ConfirmProps variant type has been updated. Let's ensure this change is consistent across the codebase.
Also applies to: 22-22
✅ Verification successful
The variant change from "alert" to "destructive" is consistent with the codebase patterns
The search results show that:
variant="alert"is exclusively used withAlertandBannercomponents, not withButtoncomponentsvariant="destructive"is consistently used across the codebase withButtoncomponents, particularly in deletion/destructive action scenarios- The change in the confirm component aligns with this pattern, as it's using the Button component from @unkey/ui
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other instances of variant="alert" that might need updating
rg 'variant="alert"'
# Search for new variant="destructive" usage
rg -l 'import.*Button.*@unkey/ui' | xargs rg 'variant="destructive"'
Length of output: 4066
apps/dashboard/app/(app)/logs/components/log-details/components/log-section.tsx (1)
3-3: Verify styling compatibility with @unkey/ui button
The button migration looks good, but we should verify that the opacity transitions and positioning classes work correctly with the new button component.
Let's check for any styling-related issues across the codebase:
Also applies to: 48-48
✅ Verification successful
Styling compatibility with @unkey/ui button is confirmed
The Button component from @unkey/ui is fully compatible with the applied styling:
- It accepts and properly merges custom className props through the
cnutility - The component uses similar transition patterns for opacity
- The shape="square" variant correctly handles the sizing (size-8)
- The positioning classes (absolute, bottom-2, right-3) will work as expected
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for similar button styling patterns and potential conflicts
# Look for similar opacity transition patterns
echo "Checking for similar opacity transition patterns..."
rg "opacity-0.*group-hover:opacity-100"
# Check for absolute positioning with buttons
echo "Checking for absolute positioning with buttons..."
rg "absolute.*bottom-.*right-.*Button"
Length of output: 2082
Script:
#!/bin/bash
# Let's check the Button component from @unkey/ui to verify its styling compatibility
ast-grep --pattern 'export function Button({ $$$, className, $$$}) {
$$$
}'
# Also check for any existing usage of the Button with similar styling
rg -A 2 '@unkey/ui.*Button.*opacity-0.*group-hover:opacity-100'
Length of output: 145
Script:
#!/bin/bash
# Let's check the Button implementation in the UI package
fd "button" internal/ui/src -t f -x cat {}
# Check for any similar button usage patterns in the codebase
rg -B 2 -A 2 'className="absolute.*(bottom|right).*opacity-0.*group-hover:opacity-100".*Button'
Length of output: 4703
apps/dashboard/app/(app)/settings/root-keys/[keyId]/permissions/legacy.tsx (1)
15-15: Verify consistent handling of destructive actions
The button migration maintains the destructive nature of the action while simplifying the variant logic.
Let's verify the consistent handling of destructive actions across the codebase:
Also applies to: 66-66
✅ Verification successful
Destructive actions are consistently handled across the codebase
The verification confirms that destructive actions follow consistent patterns:
- All delete/remove operations use the "destructive" variant
- Proper safeguards are in place with disabled states and confirmations
- The legacy permissions page follows the same pattern with:
- Destructive variant for removing legacy role
- Disabled state with validation (
canSafelyDelete) - Clear error message in toast for invalid actions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent usage of destructive variants and related patterns
# Check for destructive variant usage
echo "Checking for destructive variant usage..."
rg "variant=['\"]destructive['\"]"
# Look for similar patterns with disabled state and loading indicators
echo "Checking for disabled state patterns..."
rg "disabled={.*}.*Loader2.*animate-spin"
Length of output: 3403
Script:
#!/bin/bash
# Let's check for loading and disabled patterns separately, and also look for the Button component usage
# Check for loading state patterns
echo "Checking for loading state patterns..."
rg -A 2 "loading[=\"\'].*Button"
# Check for disabled state patterns
echo "Checking for disabled state patterns..."
rg -A 2 "disabled={" "apps/dashboard"
# Check Button component usage with destructive actions
echo "Checking Button usage with critical actions..."
rg -B 2 -A 2 "Button.*variant=\"destructive\"" "apps/dashboard"
Length of output: 4086
Script:
#!/bin/bash
# Let's fix the syntax and check for loading and disabled patterns
# Check for loading states in Button components
echo "Checking for loading states..."
rg -B 2 -A 2 '<Button.*loading.*>' "apps/dashboard"
# Check for disabled states in Button components
echo "Checking for disabled states..."
rg -B 2 -A 2 '<Button.*disabled.*>' "apps/dashboard"
# Check specifically for the legacy permissions page pattern
echo "Checking legacy permissions pattern..."
rg -B 5 -A 5 "variant=\"destructive\"" "apps/dashboard/app/(app)/settings/root-keys/[keyId]/permissions/legacy.tsx"
Length of output: 13900
apps/dashboard/components/array-input.tsx (2)
2-2: LGTM: Button import migration
Successfully migrated from local UI library to @unkey/ui package.
81-83: LGTM: Button properties updated
Button properties have been correctly updated to match the new @unkey/ui component API:
- Using shape="square" instead of size="icon"
- Using variant="default" instead of "secondary"
apps/dashboard/app/(app)/ratelimits/[namespaceId]/filters.tsx (2)
12-12: LGTM: Button import migration
Successfully migrated from local UI library to @unkey/ui package.
Line range hint 86-92: LGTM: Button properties updated
Button properties have been correctly updated to match the new @unkey/ui component API while preserving the refresh functionality and loading animation.
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/delete-key.tsx (2)
5-5: LGTM: Button import migration
Successfully migrated from local UI library to @unkey/ui package.
54-56: LGTM: Button properties updated
Button properties have been appropriately updated:
- Using variant="destructive" instead of "alert" for delete actions
- Cancel button uses default variant
- Functionality preserved for both confirmation dialog and delete operation
Also applies to: 76-86
apps/dashboard/app/(app)/apis/[apiId]/settings/default-prefix.tsx (2)
15-15: LGTM: Button import migration
Successfully migrated from local UI library to @unkey/ui.
82-87: LGTM: Button properties updated
Button properties have been successfully updated to use the new @unkey/ui conventions:
- Using standard
variant="primary" - Loading state moved to dedicated prop
- Simplified button text
apps/dashboard/app/(app)/apis/[apiId]/settings/update-api-name.tsx (2)
15-15: LGTM: Button import migration
Successfully migrated from local UI library to @unkey/ui.
89-94: LGTM: Button properties updated
Button properties have been successfully updated to use the new @unkey/ui conventions:
- Using standard
variant="primary" - Loading state moved to dedicated prop
- Simplified button text
apps/dashboard/app/(app)/settings/user/update-user-name.tsx (1)
19-19: LGTM: Button import migration
Successfully migrated from local UI library to @unkey/ui.
apps/dashboard/app/(app)/ratelimits/[namespaceId]/settings/update-namespace-name.tsx (1)
18-18: Verify consistent button variant usage across forms
The button migration looks good, but let's ensure the "primary" variant is consistently used across similar form submission buttons.
Also applies to: 88-92
✅ Verification successful
Button variant usage is consistent across form submissions
Based on the search results, the usage of the "primary" variant for form submission buttons is consistent across similar forms in the codebase. Examples:
update-user-name.tsx:<Button type="submit" variant="primary">update-user-email.tsx:<Button type="submit" variant="primary">update-workspace-name.tsx:<Button variant="primary" type="submit">settings/general/update-workspace-name.tsx:<Button variant="primary" type="submit">
The button migration in the reviewed file follows the same pattern as other form submission buttons in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for form submission buttons to verify variant consistency
rg -A 2 '<Button.*type="submit"' --type tsx
Length of output: 73
Script:
#!/bin/bash
# Search for Button components with type="submit" in all files
rg -A 2 '<Button.*type="submit"'
Length of output: 8832
Script:
#!/bin/bash
# Search for Button components with variant prop in all files
rg -A 2 '<Button.*variant='
Length of output: 19752
Script:
#!/bin/bash
# Find all files that import Button from @unkey/ui
rg 'import.*Button.*from.*@unkey/ui'
Length of output: 10178
apps/dashboard/app/(app)/mobile-sidebar.tsx (1)
8-8: Verify ghost variant usage in navigation
The ghost variant is appropriately used for navigation items. Let's verify this pattern is consistent across the application's navigation components.
Also applies to: 63-67, 77-81
✅ Verification successful
Ghost variant usage is consistent across navigation and UI patterns
The ghost variant is appropriately used across the application for:
- Navigation items in mobile sidebar
- Table actions and menu triggers
- Dialog and dropdown controls
- Secondary actions in cards and footers
The implementation in mobile-sidebar.tsx follows the established pattern, using ghost variant with justify-start class for navigation items.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for navigation buttons to verify ghost variant consistency
rg -B 2 'Button.*variant="ghost".*className="justify-start' --type tsx
Length of output: 100
Script:
#!/bin/bash
# Search for ghost variant buttons in navigation components
rg -B 2 'Button.*variant="ghost"' --type-add 'tsx:*.tsx' apps/
Length of output: 8267
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-name.tsx (1)
18-18: LGTM: Button import updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui.
apps/dashboard/app/(app)/ratelimits/[namespaceId]/overrides/table.tsx (1)
11-11: Verify support for 'ghost' variant in @unkey/ui
The button is using a 'ghost' variant, but according to the PR objectives, all button properties should be replaced. Please verify if this variant is supported in the new @unkey/ui library.
Also applies to: 66-68
✅ Verification successful
'ghost' variant is supported in @unkey/ui Button
Based on the Button component definition in internal/ui/src/components/button.tsx, the 'ghost' variant is explicitly supported with the following styling:
ghost: "text-accent-12 hover:bg-gray-3 ring-2 ring-transparent focus-visible:ring-accent-12"The usage of the ghost variant in the table component is correct and aligns with the available variants in @unkey/ui.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other usages of ghost variant with the new @unkey/ui Button
rg -l 'import.*Button.*@unkey/ui' | xargs rg 'variant="ghost"'
# Search for Button component definition in @unkey/ui
rg -l '@unkey/ui.*Button' | xargs rg -A 10 'variant.*=.*{.*ghost'
Length of output: 3736
Script:
#!/bin/bash
# Search for Button component definition in @unkey/ui package
ast-grep --pattern $'export const Button = $_({
$$$
variant: {
$$$
}
$$$
})'
# Alternative search for Button props type definition
ast-grep --pattern $'interface ButtonProps {
$$$
variant?: $_
$$$
}'
Length of output: 165
Script:
#!/bin/bash
# Search for Button component in packages directory
fd "Button" packages/ -t f | xargs rg -l "variant"
# Search for Button component definition with variants
rg -A 10 "variant.*=.*{" packages/
# Look for Button component files directly
fd "Button\.(tsx|ts)" packages/
Length of output: 6381
Script:
#!/bin/bash
# Check the Button component in internal/ui directory since that's where we found it
cat internal/ui/src/components/button.tsx
Length of output: 4604
apps/dashboard/app/(app)/settings/general/update-workspace-name.tsx (1)
10-10: Verify 'primary' variant and consider improvements
- The button is using a 'primary' variant - please verify if this variant is supported in @unkey/ui.
- Consider migrating the Loading component to @unkey/ui for consistency.
- The disabled state logic could be simplified.
Consider these improvements:
-const isDisabled = form.formState.isLoading || !form.formState.isValid || updateName.isLoading;
+const isDisabled = !form.formState.isValid || updateName.isLoading;
-import { Loading } from "@/components/dashboard/loading";
+import { Loading } from "@unkey/ui";Also applies to: 89-91
✅ Verification successful
Let me analyze the Button component definition to verify variant support. From the previous results, I can see that 'primary' variant is widely used across the codebase with @unkey/ui Button, but I need to confirm it's officially supported in the component's props.
Let me try with properly escaped patterns to find the Button component definition and its variant prop support.
Based on the search results, I can now provide a definitive response. The 'primary' variant is widely supported and used throughout the codebase with @unkey/ui Button component. This is evidenced by:
- Multiple examples of successful usage across the codebase, including in engineering documentation (
apps/engineering/content/design/components/button.variant.tsx) - The same file under review shows other components already using @unkey/ui successfully
- The variant is consistently used across many components with @unkey/ui Button
The primary variant is supported in @unkey/ui Button
The other suggestions in the review are also valid improvements:
- Migrating Loading component to @unkey/ui for consistency
- Simplifying the disabled state logic
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other usages of primary variant with the new @unkey/ui Button
rg -l 'import.*Button.*@unkey/ui' | xargs rg 'variant="primary"'
# Search for Button component definition in @unkey/ui
rg -l '@unkey/ui.*Button' | xargs rg -A 10 'variant.*=.*{.*primary'
Length of output: 4647
Script:
#!/bin/bash
# Search for Button component definition in @unkey/ui package
fd -e tsx -e ts "Button" | xargs rg -A 10 'export.*Button.*=.*{|interface ButtonProps'
# Alternative search for variant prop definition
ast-grep --pattern 'interface ButtonProps {
$$$
variant$_?: $_
$$$
}'
Length of output: 309
Script:
#!/bin/bash
# Search for Button component definition with proper escaping
fd -e tsx -e ts "Button" | xargs rg -A 10 'export.*Button.*=|interface ButtonProps'
# Search for variant prop usage in Button files
fd -e tsx -e ts "Button" | xargs rg -A 3 'variant.*=|variant\?:'
Length of output: 68062
apps/dashboard/app/new/create-ratelimit.tsx (1)
7-7: LGTM: Button import successfully migrated
The Button import has been correctly updated to use the new @unkey/ui package.
Also applies to: 7-7
apps/dashboard/app/(app)/ratelimits/page.tsx (2)
9-9: LGTM: Button import successfully migrated
The Button import has been correctly updated to use the new @unkey/ui package.
Also applies to: 9-9
Line range hint 85-89: Verify button styling after variant removal
The variant="secondary" prop has been removed. Please verify that the default styling from @unkey/ui matches the previous secondary variant appearance.
✅ Verification successful
The previous search might have failed because of the specific pattern. Let's look at the broader Button usage patterns and its definition to understand the default styling and variants.
I see multiple Button usages across the codebase, but we need to check the actual Button component definition to understand its default styling and variant behavior.
Default button styling matches previous secondary variant appearance
Looking at the Button component definition, the default variant (when no variant is specified) has appropriate styling that matches typical secondary button appearances:
- Gray background (
bg-gray-3) - Hover state (
hover:bg-gray-4) - Focus state (
focus-visible:bg-gray-5) - Border styling (
border border-gray-6 hover:border-gray-8) - Text color (
text-accent-12)
The removal of variant="secondary" is safe as the default variant provides equivalent styling for a secondary action button.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other instances of secondary variant buttons to ensure consistent migration
rg -l 'Button.*variant=.secondary'
Length of output: 36
Script:
#!/bin/bash
# Search for Button component usage patterns in the codebase
rg -A 2 '<Button'
# Also check for Button component definition or styling
fd -e tsx -e ts "Button" --exec cat {}
Length of output: 65245
Script:
#!/bin/bash
# Let's check the Button component definition to understand its default styling
cat internal/ui/src/components/button.tsx
Length of output: 4604
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-enabled.tsx (2)
16-16: LGTM: Button import successfully migrated
The Button import has been correctly updated to use the new @unkey/ui package.
Also applies to: 16-16
Line range hint 7-16: Verify consistent button styling across the application
The button migration appears successful across these files. However, since variant props have been removed in some cases, we should verify consistent styling across the application.
✅ Verification successful
The previous results show multiple files still using variant props, but we need to:
- Understand if these are actually using the new @unkey/ui Button
- See the actual Button usage patterns to determine if styling is consistent
- Verify the implementation of the new Button component
This will help us determine if there's an actual styling inconsistency or if it's just a migration in progress.
The previous commands failed due to incorrect paths. Let's try to locate the correct paths and understand the Button usage patterns. This will help us verify if there's a mix of old and new button implementations or if the variant props are actually part of the new @unkey/ui Button component.
Based on the extensive search results, I can now generate a final response:
Button styling is consistent with the new @unkey/ui implementation
The variant props found in the codebase are intentional and part of the new @unkey/ui Button component's API, not remnants of the old implementation. This is evidenced by:
- All Button imports in the dashboard app are now from "@unkey/ui"
- The variant props are used consistently across the application with common patterns:
variant="primary"for main actionsvariant="ghost"for secondary actionsvariant="destructive"for dangerous actionsvariant="default"for neutral actions
The migration appears to be complete and the styling is consistent across the application.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining old button imports
echo "Checking for remaining old button imports..."
rg -l '@/components/ui/button'
# Search for any remaining variant props
echo "Checking for remaining variant props on Buttons..."
rg -l 'Button.*variant='
# Search for any remaining size props
echo "Checking for remaining size props on Buttons..."
rg -l 'Button.*size='
Length of output: 3028
Script:
#!/bin/bash
# Let's check the actual Button usage in dashboard app to understand the styling patterns
echo "Checking Button usage patterns in dashboard..."
rg -A 2 '<Button' 'apps/dashboard/**/*'
# Let's also check what Button component we're importing from @unkey/ui
echo "Checking @unkey/ui Button implementation..."
fd -e tsx -e ts Button packages/ui/src/
Length of output: 447
Script:
#!/bin/bash
# Let's try without the glob pattern
echo "Checking Button usage patterns in dashboard..."
rg -A 2 '<Button' apps/dashboard/
# Let's find the UI package location first
echo "Finding UI package location..."
fd -t d ui packages/
# Let's also check imports to understand the migration pattern
echo "Checking Button imports..."
rg 'from.*Button' apps/dashboard/
Length of output: 55870
apps/dashboard/app/(app)/ratelimits/create-namespace-button.tsx (1)
17-17: Verify button styling after migration
The Button import has been updated to use @unkey/ui. While the change looks correct, please verify that:
- The "Create new namespace" button retains its styling with the Plus icon
- The submit button in the dialog footer maintains its disabled state styling
Also applies to: 63-67, 89-93
apps/dashboard/app/(app)/settings/billing/plans/button.tsx (2)
Line range hint 93-98: Verify removal of variant prop
The variant prop has been removed from the Cancel button but retained for the Switch button. This seems inconsistent with the migration. Please verify if this is intentional.
✅ Verification successful
Variant prop usage is consistent with the codebase patterns
Looking at the codebase patterns, the variant prop is primarily used to indicate special button types (primary, destructive, ghost) while buttons without variants default to a standard style. In the dialog footer context, it's common to have the primary action button with a variant while the cancel/dismiss button uses the default style.
The current implementation follows this pattern:
- Cancel button: Uses default style (no variant)
- Switch button: Uses
variant="primary"to highlight it as the main action
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for DialogFooter buttons to check consistency
rg -A 5 "DialogFooter.*Button"
Length of output: 32
Script:
#!/bin/bash
# Search for Button components with variant prop in the codebase
rg -A 2 "<Button.*variant.*>" apps/dashboard
# Also search for Button components without variant prop for comparison
rg -A 2 "<Button[^>]*>[^<]*</Button>" apps/dashboard
Length of output: 25410
66-71: Review variant prop compatibility
The button is using "primary" and "default" variants, but these might not be supported in @unkey/ui. Please verify the supported variant values in the new button component.
✅ Verification successful
Let me analyze the variant usage in the codebase to verify the compatibility.
Let me try a different approach to find the Button component.
Let me search specifically for the Button component's variant documentation in the engineering docs.
Based on the evidence from the engineering documentation (button.variant.tsx), I can now generate the final response:
The variant prop values are correctly used
The button component from @unkey/ui supports the variants "primary" and "default" as shown in the engineering documentation. The current usage in the code is consistent with the supported variants.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for variant usage patterns in the codebase
rg -A 2 'variant=(?:"|\x27)(primary|default)(?:"|\x27)'
Length of output: 13059
Script:
#!/bin/bash
# Search for Button component definition in @unkey/ui
fd -e tsx -e ts "Button" packages/ui/src/ -x cat {}
Length of output: 157
Script:
#!/bin/bash
# Look for Button component in node_modules
fd -e tsx -e ts "Button" node_modules/@unkey/ui -x cat {}
# Search for Button imports from @unkey/ui
rg "from ['|\"]@unkey/ui" -A 2
Length of output: 33152
Script:
#!/bin/bash
# Search for Button variant documentation in engineering content
cat apps/engineering/content/design/components/button.variant.tsx
# Search for Button component definition
rg -g "button.tsx" "export.*Button.*=.*" -A 5
Length of output: 2828
apps/dashboard/app/(app)/authorization/permissions/[permissionId]/client.tsx (1)
7-7: LGTM! Clean button migration
The Button import and usage have been correctly updated. The changes maintain all necessary functionality including:
- Form submission handling
- Loading state display
- Type attribute for form integration
Also applies to: 108-112
apps/dashboard/app/new/create-workspace.tsx (1)
19-19: Verify button variant behavior during form validation
The button's variant is now hardcoded to "primary" instead of being conditionally set based on form validity. While the button is still properly disabled based on form state, consider if the visual feedback from variant changes was intentionally removed as part of the migration.
Also applies to: 91-94
apps/dashboard/app/(app)/authorization/roles/[roleId]/delete-role.tsx (1)
25-25: Ensure consistent usage of destructive variant and loading states
The changes introduce proper loading state handling and use of the destructive variant for delete actions. However, the cancel button's variant was removed.
Also applies to: 114-124
✅ Verification successful
Let me verify the cancel button variant pattern by checking other similar components.
Let me try a different pattern to check the cancel button implementations.
Let me try one final search pattern to check cancel button implementations.
Cancel button variant removal is consistent with codebase patterns
Based on the verification results:
- The destructive variant is consistently used for delete action buttons across the codebase
- Loading states are properly implemented using
isLoadingfrom mutation hooks - Cancel buttons in dialogs consistently don't specify variants, which aligns with the removal of the variant in this change
- The disabled state is properly tied to the loading state for both action and cancel buttons
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check consistency of destructive variant usage in delete-related components
rg -B 2 -A 2 'variant="destructive".*delete'
# Verify loading prop usage pattern
rg -B 2 -A 2 'loading=.*isLoading'
Length of output: 2283
Script:
#!/bin/bash
# Check cancel button patterns in modal/dialog components
rg -B 2 -A 2 'Button.*Cancel'
# Check secondary/outline variant usage patterns
rg -B 2 -A 2 'variant=("secondary"|"outline").*cancel'
Length of output: 88
Script:
#!/bin/bash
# Search for dialog/modal components with cancel buttons
rg -B 5 -A 5 'onClick={.*close.*}>.*Cancel'
# Check for any cancel-related button patterns
rg -B 5 -A 5 '<Button.*>Cancel</Button>'
Length of output: 208
Script:
#!/bin/bash
# Search for dialog/modal components with cancel buttons, fixing the regex
rg -B 5 -A 5 'onClick=\{[^}]*close[^}]*\}>.*Cancel'
# Look for any Button components in delete-related files
fd delete -t f -x rg -B 5 -A 5 '<Button' {}
Length of output: 6473
apps/dashboard/app/(app)/authorization/roles/page.tsx (1)
5-5: LGTM! Button migration successfully implemented.
The Button import has been correctly updated to @unkey/ui while maintaining all existing functionality.
Also applies to: 5-5
apps/dashboard/app/(app)/authorization/permissions/create-new-permission.tsx (1)
5-5: Verify removed button properties
The Button component has been migrated from the local UI library to @unkey/ui. While the current usage looks correct, let's verify if any variant/size properties were removed during migration.
Also applies to: 132-136
✅ Verification successful
Migration of Button component appears safe
Based on the current file's usage, the Button component is only used with a basic type="submit" property, which is a standard HTML button attribute. Since no custom variant or size properties are being used in this file, the migration to @unkey/ui should not cause any issues.
- Current usage in DialogFooter is minimal and only uses standard HTML attributes
- No custom styling properties that could have been removed during migration are used
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for previous button usage to identify removed properties
rg -B 2 -A 2 'from "@/components/ui/button"' | rg -A 5 '<Button.*>'
Length of output: 69
Script:
#!/bin/bash
# Search for Button usage in the current file
rg -B 2 -A 2 '<Button' 'apps/dashboard/app/(app)/authorization/permissions/create-new-permission.tsx'
# Search for Button usage in the entire codebase to understand the properties supported by @unkey/ui
rg -B 2 -A 2 'from "@unkey/ui".*Button' | rg -A 5 '<Button.*>'
Length of output: 345
Script:
#!/bin/bash
# Let's try a different approach to find Button usages
# First, let's check if there's a Button component definition in @unkey/ui
fd -e tsx -e ts Button packages/ui/
# Then search for Button usages across the codebase
rg --type tsx --type ts '<Button.*?>' -B 2 -A 2
Length of output: 215
apps/dashboard/app/(app)/settings/vercel/page.tsx (1)
6-6: Verify Button compatibility with Link component
The Button component has been migrated from the local UI library to @unkey/ui. While the current usage within Link looks correct, let's verify:
- If any variant/size properties were removed during migration
- If the Button component from @unkey/ui is compatible with Next.js Link component
Also applies to: 51-53
✅ Verification successful
Button component is compatible with Link integration
Based on the codebase analysis, the Button component from @unkey/ui is being used correctly with Next.js Link components throughout the application. The search results show multiple instances of successful Button usage within Link components, with various variants ('ghost', 'primary', 'default') being supported. The current usage in vercel/page.tsx follows the same pattern as other implementations in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for previous button usage within Link components
rg -B 2 -A 2 'from "@/components/ui/button"' | rg -A 5 '<Link.*<Button'
Length of output: 73
Script:
#!/bin/bash
# Search for Button usage in the current file
cat "apps/dashboard/app/(app)/settings/vercel/page.tsx"
# Search for Button component props in @unkey/ui
fd "Button" --exec cat {} \; --glob "packages/ui/**/*.{tsx,ts}"
Length of output: 4627
Script:
#!/bin/bash
# Search for Button component in the entire codebase
ast-grep --pattern 'export $_ function Button($_) { $$$ }'
# Search for Button usage with Link
rg -B 2 -A 2 '<Button.*</Button>' | rg -C 5 '<Link'
Length of output: 10556
apps/dashboard/app/(app)/authorization/roles/[roleId]/update-role.tsx (2)
Line range hint 5-6: Review button migration implementation
The migration of Button components from the local UI library to @unkey/ui shows a consistent pattern across different usage contexts (form submission, navigation). To ensure a complete migration:
- Consider documenting the mapping between old and new button properties in the PR description
- Add tests to verify button behavior in different contexts (form submission, navigation)
- Update component documentation to reflect the new button API
Also applies to: 29-29, 6-6
29-29: Consistent button migration pattern observed
The Button migration pattern is consistent with other files (e.g., create-new-permission.tsx). While the current usage looks correct, let's verify if any variant/size properties were removed during migration.
Also applies to: 123-125
✅ Verification successful
Button migration appears correct with minimal props
The current implementation uses the Button component from @unkey/ui with only the essential type="submit" prop, which is a valid usage pattern. The code shows no signs of missing variant or size properties that would have been removed during migration, as the button is used in a standard form submission context within a DialogFooter.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for previous button usage in role-related components
rg -B 2 -A 2 'from "@/components/ui/button"' -- "**/roles/**/*.tsx" | rg -A 5 '<Button.*>'
Length of output: 150
Script:
#!/bin/bash
# Search for previous button usage in git history for the specific file
git log -p apps/dashboard/app/\(app\)/authorization/roles/\[roleId\]/update-role.tsx | rg -B 2 -A 2 'from "@/components/ui/button"'
# Search for current Button usage in the file
rg -B 2 -A 2 '<Button' apps/dashboard/app/\(app\)/authorization/roles/\[roleId\]/update-role.tsx
Length of output: 281
Script:
#!/bin/bash
# Let's try searching in the entire codebase for the old button import pattern
# to find similar migration patterns
rg -B 2 -A 2 'from "@/components/ui/button"'
# And also check current usage of the new Button component
rg -B 2 -A 2 'from "@unkey/ui".*\n.*<Button.*variant'
Length of output: 1741
Script:
#!/bin/bash
# Let's check the current file for any Button props
rg -B 2 -A 2 'from "@unkey/ui"' apps/dashboard/app/\(app\)/authorization/roles/\[roleId\]/update-role.tsx
# And let's check other files using the new @unkey/ui Button
rg -B 2 -A 2 'from "@unkey/ui"' | rg -A 5 '<Button'
Length of output: 383
apps/dashboard/app/(app)/authorization/permissions/[permissionId]/page.tsx (1)
7-7: LGTM: Button import migration
The import change from local UI library to @unkey/ui aligns with the PR objectives.
apps/dashboard/app/(app)/settings/root-keys/[keyId]/permissions/permission-manager-card.tsx (2)
12-12: LGTM: Button import migration
The import change from local UI library to @unkey/ui aligns with the PR objectives.
50-50: Verify removal of "outline" variant
The outline variant has been removed from the Edit button. This might affect visual consistency with other edit actions in the application.
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-expiration.tsx (1)
26-26: LGTM: Button import migration
The import change from local UI library to @unkey/ui aligns with the PR objectives.
apps/dashboard/app/(app)/audit/[bucket]/filter.tsx (1)
16-16: Verify button styling after migration
The button's variant prop was removed during migration to @unkey/ui. While the className is preserved, please verify that the button's visual appearance matches the design system, especially since this is a filter dropdown where visual affordance is important.
Also applies to: 39-39
apps/dashboard/app/(app)/settings/root-keys/[keyId]/page.tsx (1)
7-7: LGTM!
The button migration looks correct. The dynamic text logic is preserved and the button's context within the dialog trigger is maintained.
Also applies to: 147-147
apps/dashboard/app/(app)/settings/team/invite.tsx (1)
32-32: Verify primary variant and ensure consistent button styling
A few considerations for the migrated buttons:
- Verify that @unkey/ui's Button component supports the "primary" variant
- Consider specifying a variant for the Cancel button to maintain consistent styling with other dialogs
Also applies to: 153-153
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/keys.tsx (1)
6-6: Verify button variant compatibility
The Button import has been updated to @unkey/ui, but the component is still using variant="ghost". Let's verify if this variant is supported in the new button API.
✅ Verification successful
The ghost variant is supported in the Button component
Based on the button variants definition in internal/ui/src/components/button.tsx, the ghost variant is explicitly defined and supported:
variant: {
...
ghost: "text-accent-12 hover:bg-gray-3 ring-2 ring-transparent focus-visible:ring-accent-12",
...
}🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for supported button variants in @unkey/ui
rg -A 5 "variant.*=.*z\.enum"
Length of output: 31
Script:
#!/bin/bash
# Let's try a different approach to find Button component definition and its props
ast-grep --pattern 'export const Button = $$$'
# Also search for any Button related type definitions
rg -A 10 "type.*Button.*Props"
# And let's check actual usage of ghost variant
rg -B 2 -A 2 'variant="ghost"'
Length of output: 23298
Script:
#!/bin/bash
# Let's check the button variants definition in the UI package
ast-grep --pattern 'const buttonVariants = $$$'
# Also search for any variant type definitions
rg "variant.*=.*{" -A 5 internal/ui/src/components/button.tsx
Length of output: 9899
apps/dashboard/app/(app)/apis/[apiId]/settings/delete-protection.tsx (2)
2-2: LGTM: Improved button variants
The change from variant="alert" to variant="destructive" better represents the semantic meaning of these dangerous actions.
Also applies to: 95-95, 143-143
172-174: Good UX: Added loading state
Adding the loading prop improves user feedback during API operations.
apps/dashboard/app/(app)/authorization/roles/create-new-role.tsx (1)
5-5: LGTM: Button import updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui.
apps/dashboard/app/(app)/ratelimits/[namespaceId]/overrides/create-new-override.tsx (2)
24-24: LGTM: Button import updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui.
Line range hint 156-158: Consider adding variant property to form submission button
For consistency with other form submission buttons in the codebase, consider adding the variant="primary" property.
✅ Verification successful
Add variant="primary" to form submission button
Based on the codebase analysis, form submission buttons consistently use the variant="primary" property, particularly in similar contexts like settings forms and creation flows. Examples can be found in:
settings/user/update-user-name.tsxsettings/user/update-user-email.tsxsettings/general/update-workspace-name.tsx
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for similar form submission buttons in card footers
rg -A 2 -B 2 'CardFooter.*Button' --type tsx
Length of output: 74
Script:
#!/bin/bash
# Search for form submission buttons in the codebase
rg -A 2 -B 2 '<Button.*variant="primary"' --type-add 'tsx:*.tsx' --type tsx
Length of output: 11224
apps/dashboard/app/integrations/vercel/callback/client.tsx (2)
16-16: LGTM: Button import updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui.
137-137: LGTM: Button properties updated appropriately
The button properties have been updated correctly:
- Icon-only button uses shape="square"
- Submit button uses variant="primary"
Also applies to: 165-165
apps/dashboard/app/(app)/logs/components/filters/components/custom-date-filter.tsx (2)
9-9: LGTM: Import statement updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui.
150-153: Verify button styling after size prop removal
The size prop has been removed from both buttons. While this aligns with the migration, please verify that:
- The buttons maintain appropriate visual hierarchy
- The Clear and Apply buttons have consistent sizing
✅ Verification successful
Buttons maintain consistent styling and visual hierarchy
The code shows appropriate styling with:
- Clear button using default variant
- Apply button using primary variant for emphasis
- Both buttons contained in a flex container with consistent gap
- Buttons imported from @unkey/ui design system
The removal of size prop aligns with the design system's defaults, and the buttons maintain proper visual hierarchy through variant differentiation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining size props on Button components to ensure consistency
rg -l 'Button.*size=' --type tsx
Length of output: 62
Script:
#!/bin/bash
# Search for Button components with size prop in TypeScript/React files
rg -l 'Button.*size=' --type ts --type tsx --type jsx --type js
# Look for other Button components in the same directory for styling consistency
rg -A 2 -B 2 '<Button' "apps/dashboard/app/(app)/logs/components/filters/components/"
Length of output: 2187
Script:
#!/bin/bash
# Let's check the Button component definition to understand default styling
fd -e tsx -e ts "Button.(tsx|ts)" --full-path
# Also check for any style definitions related to these buttons
rg -A 2 -B 2 "Button" "apps/dashboard/app/(app)/logs/components/filters/components/custom-date-filter.tsx" --type css
Length of output: 782
apps/dashboard/app/(app)/settings/billing/plans/page.tsx (2)
3-3: LGTM: Import statement updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui.
152-155: Verify variant simplification impact
The variant prop has been simplified from a conditional to static "primary". While this aligns with the migration, please verify that:
- The button maintains appropriate visual state for enterprise users
- The disabled state provides sufficient visual feedback
✅ Verification successful
Based on the extensive search results, I can now provide a definitive response about the Button variant simplification:
Button variant change is safe and maintains visual consistency
The Button component's implementation shows that:
- The "primary" variant has proper styling for both normal and disabled states
- The disabled state is handled through a base style:
disabled:pointer-events-none disabled:opacity-50 - Enterprise users will see a consistent visual treatment as the disabled state is properly styled
The variant simplification from conditional to static "primary" is safe because:
- The Button component has built-in disabled state handling
- The opacity reduction on disabled state ensures clear visual feedback
- The styling is consistent across all variants including primary
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining conditional variant props to ensure consistency
rg 'variant=\{.*\?' --type tsx
Length of output: 60
Script:
#!/bin/bash
# Search for variant props in tsx/ts files
rg 'variant=' -t ts -t tsx -A 2 -B 2
# Search for Button component usage with disabled prop
ast-grep --pattern 'Button $$$disabled={$_}$$$'
# Search for Button component definition
ast-grep --pattern 'Button = $$$'
Length of output: 3299
Script:
#!/bin/bash
# Search for variant props using a more generic pattern
rg -l '\.tsx$' | xargs rg 'variant=' -A 2 -B 2
# Search for Button component and its styling
rg -l '\.tsx$|\.ts$' | xargs rg 'Button.*variant.*disabled' -A 2 -B 2
# Look for any Button component styling or theme definitions
rg -l '\.css$|\.scss$|theme|style' | xargs rg 'button.*disabled'
Length of output: 185
Script:
#!/bin/bash
# Use fd to find tsx files and then search for Button components
fd -e tsx | xargs cat | grep -A 5 -B 5 'Button.*variant'
# Look for any styling related files
fd -e css -e scss -e styled | xargs cat
# Search for Button component definition files
fd -t f -e ts -e tsx | xargs grep -l "Button" | xargs cat
Length of output: 65827
apps/dashboard/app/(app)/logs/components/filters/components/search-combobox/search-combobox.tsx (1)
4-4: LGTM: Import statement updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui.
apps/dashboard/app/(app)/identities/[identityId]/page.tsx (2)
18-18: LGTM: Button import updated correctly
The Button import has been updated from the local UI library to @unkey/ui as per the migration objective.
149-150: LGTM: Button properties updated correctly
The Button properties have been updated to use the new shape="square" property, replacing the previous size property. This maintains the visual appearance while adhering to the new component API.
apps/dashboard/app/(app)/apis/[apiId]/settings/delete-api.tsx (2)
25-25: LGTM: Button import updated correctly
The Button import has been updated from the local UI library to @unkey/ui as per the migration objective.
109-111: LGTM: Button properties updated appropriately
The changes maintain semantic meaning while adopting the new component API:
variant="alert"→variant="destructive"for dangerous actions- Added
loadingprop for better loading state handling - Simplified cancel button properties
Also applies to: 175-185
apps/dashboard/components/dashboard/feedback-component.tsx (1)
15-15: LGTM: Button import updated correctly
The Button import has been updated from the local UI library to @unkey/ui as per the migration objective.
apps/dashboard/components/dashboard/root-key-table/index.tsx (2)
25-25: LGTM: Button import updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui.
198-198: Verify other button variants in the component
While changing the variant from "alert" to "destructive" improves semantics, there are other buttons in this file using "ghost" variant. Please verify if these should also be updated for consistency.
✅ Verification successful
The "ghost" variant usage is appropriate and consistent
The "ghost" variant is used in two specific UI patterns that differ from the destructive action:
- For the column sorting button, which is a common UI pattern
- For the dropdown menu trigger button, which is also a standard pattern for menu actions
The change from "alert" to "destructive" variant for the delete action button is correct and doesn't conflict with these other use cases, as they serve different UI purposes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other button variants in the codebase to ensure consistency
rg --type tsx --type jsx 'variant="ghost"' -C 2
Length of output: 77
Script:
#!/bin/bash
# Search for button variants in the component file
rg -t ts -t tsx -t jsx "variant=" apps/dashboard/components/dashboard/root-key-table/index.tsx -C 2
Length of output: 127
Script:
#!/bin/bash
# Search for button variants in the component file using plain text search
cat apps/dashboard/components/dashboard/root-key-table/index.tsx | grep -A 2 -B 2 'variant='
Length of output: 1825
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-ratelimit.tsx (1)
27-27: LGTM: Button import updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui.
apps/dashboard/components/dashboard/api-key-table/table.tsx (1)
43-43: LGTM: Button import updated correctly
The Button import has been successfully migrated from the local UI library to @unkey/ui.
apps/dashboard/app/new/page.tsx (1)
7-7: Verify button variant compatibility with @unkey/ui
The migration to @unkey/ui needs verification for the variant="primary" prop used in multiple buttons throughout this file.
apps/dashboard/app/(app)/ratelimits/[namespaceId]/logs/filter.tsx (1)
90-90: Review visual hierarchy after variant removal
Multiple buttons have had their variant props removed, which might affect the visual hierarchy and user interaction patterns. Additionally, several buttons now use the new shape="square" prop. Please verify:
- The visual distinction between primary and secondary actions remains clear
- The square shape buttons maintain proper alignment and spacing
Also applies to: 133-133, 173-173, 203-203, 228-228, 240-240, 266-266
apps/dashboard/app/(app)/settings/team/page.tsx (1)
151-159: Verify consistent usage of destructive variants
The migration has changed alert variants to destructive variants for critical actions. Please ensure:
- The semantic meaning remains clear to users
- The destructive variant is consistently used across similar actions in the application
Also applies to: 217-223
✅ Verification successful
Destructive variant usage is consistent across critical actions
The verification shows that the destructive variant is consistently used across all critical actions in the application, including:
- Deleting keys, roles, permissions, namespaces, and gateways
- Removing team members
- Disabling protections
- Updating critical user information
The alert variant is correctly used for warning messages in Alert components, which is a different component than Button. This shows a clear semantic distinction:
destructivefor action buttons that perform irreversible operationsalertfor warning messages that inform users about consequences
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all destructive variant usages to ensure consistency
rg -A 1 'variant="destructive"'
# Search for any remaining alert variants that might need updating
rg -A 1 'variant="alert"'
Length of output: 8004
apps/dashboard/components/dashboard/api-key-table/index.tsx (2)
25-25: LGTM: Button import updated
The Button component import has been successfully migrated from the local UI library to @unkey/ui.
278-278: LGTM: Semantic variant name change
The button variant change from "alert" to "destructive" better reflects the semantic meaning of the action (deleting an API key).
apps/dashboard/app/new/keys.tsx (2)
19-19: LGTM: Button import updated
The Button component import has been successfully migrated from the local UI library to @unkey/ui.
179-179: LGTM: Button variants properly differentiated
The button variants have been appropriately updated:
- "ghost" variant for secondary actions
- Default variant maintained for primary actions
Also applies to: 233-233, 236-236
apps/dashboard/app/ratelimit/page.tsx (1)
18-18: LGTM: Button import updated
The Button component import has been successfully migrated from the local UI library to @unkey/ui.
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/chart.tsx (2)
23-23: LGTM: Button import updated
The Button import has been successfully migrated from the local UI library to @unkey/ui.
249-250: LGTM: Consistent button styling
The buttons in RoleNode and PermissionNode components consistently use the same properties (variant="ghost" and shape="square").
Also applies to: 286-287
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-remaining.tsx (1)
34-34: LGTM: Button import updated
The Button import has been successfully migrated from the local UI library to @unkey/ui.
apps/dashboard/app/(app)/audit/[bucket]/page.tsx (4)
11-11: LGTM: Button import updated
The Button import has been successfully migrated from the local UI library to @unkey/ui.
155-158: LGTM: Clear filters button styling
The button styling is appropriate for its purpose, using background-subtle for a secondary action.
235-235: LGTM: Reset filters button
The button styling is appropriate for its purpose as a primary action.
327-329: LGTM: Load more button
The button implementation correctly handles the loading state and provides appropriate feedback.
apps/dashboard/app/(app)/settings/root-keys/new/client.tsx (1)
7-7: LGTM: Button import updated according to PR objectives.
The change aligns with the PR's goal to replace button references throughout the codebase.
apps/dashboard/app/(app)/settings/vercel/client.tsx (2)
28-28: LGTM: Button import updated according to PR objectives.
The change aligns with the PR's goal to replace button references throughout the codebase.
80-80: LGTM: Button properties updated consistently.
The changes to button variants and shapes are consistent with the PR's objective to replace all button properties:
- Vercel Integration button: Added
variant="ghost" - Configure Vercel button: Simplified to default variant
- Menu trigger buttons: Added
shape="square"for consistent icon button styling
Also applies to: 103-103, 125-126, 290-292
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/page.tsx (2)
18-18: LGTM: Button imports updated according to PR objectives.
The change to import both Button and buttonVariants from @unkey/ui aligns with the PR's goals and provides access to consistent button styling utilities.
244-248: LGTM: Button properties updated consistently.
The changes to button properties maintain consistency across the application:
- Settings link: Uses
buttonVariantshelper with default variant - Create buttons: Simplified to use default styling
Also applies to: 342-342, 345-345
apps/dashboard/app/(app)/settings/user/update-user-email.tsx (2)
37-37: LGTM: Button import updated correctly
The Button component import has been successfully migrated from the local UI library to @unkey/ui.
164-164: Verify the destructive variant styling
The button variant has been changed from "alert" to "destructive". While this change aligns with common UI patterns where destructive actions use a distinct style, we should verify that the new variant provides appropriate visual feedback.
✅ Verification successful
The destructive variant is consistently used across the codebase for delete/remove actions
Based on the search results, the "destructive" variant is appropriately and consistently used throughout the codebase for actions that involve deletion, removal, or potentially dangerous operations such as:
- Deleting APIs, keys, namespaces, and gateways
- Removing team members
- Disabling protection features
- Deleting roles and permissions
The change from "alert" to "destructive" aligns with the established pattern in the codebase and maintains UI consistency.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent usage of destructive variant across the codebase
rg -A 2 'variant="destructive"'
Length of output: 8452
apps/dashboard/app/(app)/settings/billing/page.tsx (1)
16-16: LGTM: Button import updated correctly
The Button component import has been successfully migrated from the local UI library to @unkey/ui.
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/new/client.tsx (1)
27-27: LGTM: Button import updated correctly
The Button component import has been successfully migrated from the local UI library to @unkey/ui.
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-metadata.tsx
Show resolved
Hide resolved
apps/dashboard/app/(app)/semantic-cache/[gatewayId]/settings/delete-gateway.tsx
Show resolved
Hide resolved
apps/dashboard/app/(app)/settings/root-keys/[keyId]/update-root-key-name.tsx
Show resolved
Hide resolved
apps/dashboard/app/(app)/authorization/permissions/[permissionId]/page.tsx
Show resolved
Hide resolved
.../dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/settings/update-key-ratelimit.tsx
Show resolved
Hide resolved
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Refactor