-
Notifications
You must be signed in to change notification settings - Fork 595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix cancel button of class performance config modal #5159
Conversation
WalkthroughThe pull request introduces modifications to the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
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
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
app/packages/core/src/plugins/SchemaIO/components/NativeModelEvaluationView/Evaluation.tsx (3)
Line range hint
1353-1364
: Improve type safety for component propsThe
EvaluationProps
type definition could be enhanced for better type safety:type EvaluationProps = { name: string; id: string; navigateBack: () => void; loadEvaluation: (key?: string) => void; onChangeCompareKey: (compareKey: string) => void; compareKey?: string; - data: any; + data: { + evaluations?: Array<{ key: string }>; + permissions?: { can_edit_note?: boolean; can_edit_status?: boolean }; + [key: `evaluation_${string}`]: unknown; + }; - setStatusEvent: string; - setNoteEvent: string; + setStatusEvent: (params: { status: string }) => void; + setNoteEvent: (params: { note: string }) => void; statuses: Record<string, string>; notes: Record<string, string>; loadView: (type: string, params: any) => void; };
Line range hint
42-56
: Consider consolidating dialog-related statesThe state management for dialogs could be simplified by combining related states:
- const [classPerformanceConfig, setClassPerformanceConfig] = - useState<PLOT_CONFIG_TYPE>({}); - const [classPerformanceDialogConfig, setClassPerformanceDialogConfig] = - useState<PLOT_CONFIG_DIALOG_TYPE>(DEFAULT_BAR_CONFIG); + const [classPerformanceState, setClassPerformanceState] = useState({ + config: {} as PLOT_CONFIG_TYPE, + dialogConfig: DEFAULT_BAR_CONFIG as PLOT_CONFIG_DIALOG_TYPE, + isOpen: false + });This would reduce state updates and make the relationship between dialog state and configuration more explicit.
Line range hint
1166-1352
: Consider extracting dialog components for better maintainabilityThe dialog components could be extracted into separate components to improve code organization and reusability:
+ const EditNoteDialog = ({ open, onClose, onSave, defaultValue }) => ( + <Dialog open={open} fullWidth onClose={onClose}> + {/* ... existing dialog content ... */} + </Dialog> + ); + const ClassPerformanceConfigDialog = ({ open, onClose, onSave, config }) => ( + <Dialog open={open} fullWidth onClose={onClose}> + {/* ... existing dialog content ... */} + </Dialog> + ); return ( <Stack spacing={2} sx={{ p: 2 }}> {/* ... other content ... */} - <Dialog open={editNoteState.open} /* ... */}> - {/* ... dialog content ... */} - </Dialog> + <EditNoteDialog + open={editNoteState.open} + onClose={closeNoteDialog} + onSave={(note) => triggerEvent(setNoteEvent, { note })} + defaultValue={evaluationNotes} + /> {/* ... similar for other dialogs ... */} </Stack> );This would:
- Improve code readability
- Make the dialogs more reusable
- Reduce the complexity of the main component
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
app/packages/core/src/plugins/SchemaIO/components/NativeModelEvaluationView/Evaluation.tsx
(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
app/packages/core/src/plugins/SchemaIO/components/NativeModelEvaluationView/Evaluation.tsx (1)
Pattern **/*.{ts,tsx}
: Review the Typescript and React code for conformity with best practices in React, Recoil, Graphql, and Typescript. Highlight any deviations.
🔇 Additional comments (1)
app/packages/core/src/plugins/SchemaIO/components/NativeModelEvaluationView/Evaluation.tsx (1)
1353-1353
: LGTM: Dialog handlers are properly implemented
The cancel button for the class performance config modal is correctly wired to the close handler, addressing the PR's objective.
Closing in favour of #5166 |
What changes are proposed in this pull request?
fix cancel button of class performance config modal
How is this patch tested? If it is not, please explain why.
(Details)
Release Notes
Is this a user-facing change that should be mentioned in the release notes?
notes for FiftyOne users.
(Details in 1-2 sentences. You can just refer to another PR with a description
if this PR is part of a larger change.)
What areas of FiftyOne does this PR affect?
fiftyone
Python library changesSummary by CodeRabbit
New Features
Improvements
EvaluationProps
for better clarity in component properties.