chore: Expose classNames from display-settings#754
chore: Expose classNames from display-settings#754rohanchkrabrty merged 1 commit intoraystack:mainfrom
Conversation
|
@singh-pk is attempting to deploy a commit to the Raystack Team on Vercel. A member of the Team first needs to authorize it. |
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 51 minutes and 53 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (8)
📝 WalkthroughWalkthroughThe 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/raystack/components/data-table/components/display-settings.tsx`:
- Around line 20-22: The DisplaySettings component currently requires a
classNames prop which breaks callers like toolbar.tsx that render
<DisplaySettings /> with no props; make classNames optional by updating the
DisplaySettings signature to accept classNames?: { content?: string } and
provide a safe default (or fallback) when reading classNames.content (e.g., use
classNames?.content or a default string) so existing callers won’t fail
TypeScript checks or throw at runtime; update any internal references in
DisplaySettings to use the optional/fallback value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6fd011b2-716a-47e1-929c-ad9c1ecfca2a
📒 Files selected for processing (1)
packages/raystack/components/data-table/components/display-settings.tsx
| export function DisplaySettings<TData, TValue>({ | ||
| classNames | ||
| }: { classNames: { content: string } }) { |
There was a problem hiding this comment.
Keep classNames optional to avoid breaking existing callers.
packages/raystack/components/data-table/components/toolbar.tsx:17 still renders <DisplaySettings /> without props. With the new required parameter, this can fail TypeScript checks and classNames['content'] will throw at runtime if omitted.
🐛 Proposed fix
export function DisplaySettings<TData, TValue>({
classNames
-}: { classNames: { content: string } }) {
+}: { classNames?: { content?: string } } = {}) {- className={cx(styles['display-popover-content'], classNames['content'])}
+ className={cx(styles['display-popover-content'], classNames?.content)}Also applies to: 86-86
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/raystack/components/data-table/components/display-settings.tsx`
around lines 20 - 22, The DisplaySettings component currently requires a
classNames prop which breaks callers like toolbar.tsx that render
<DisplaySettings /> with no props; make classNames optional by updating the
DisplaySettings signature to accept classNames?: { content?: string } and
provide a safe default (or fallback) when reading classNames.content (e.g., use
classNames?.content or a default string) so existing callers won’t fail
TypeScript checks or throw at runtime; update any internal references in
DisplaySettings to use the optional/fallback value.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
839d7aa to
6358875
Compare
Description
Expose classNames from display-settings
Type of Change
How Has This Been Tested?
[Describe the tests that you ran to verify your changes]
Checklist:
Screenshots (if appropriate):
[Add screenshots here]
Related Issues
[Link any related issues here using #issue-number]