-
Notifications
You must be signed in to change notification settings - Fork 557
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
SliderView, DropDownView minor improvements #4993
Conversation
WalkthroughThe changes in this pull request focus on the Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
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: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
- app/packages/core/src/plugins/SchemaIO/components/SliderView.tsx (3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
app/packages/core/src/plugins/SchemaIO/components/SliderView.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 (3)
app/packages/core/src/plugins/SchemaIO/components/SliderView.tsx (3)
88-88
: 🛠️ Refactor suggestionRemove unused unit selection code.
Since unit selection has been removed, the following can be cleaned up:
- Remove the
UnitSelection
component definition- Remove the
unit
state andsetUnit
- Remove the
ValueFormat
type if not used elsewhereThis will improve code maintainability and reduce bundle size.
#!/bin/bash # Check if ValueFormat type is used elsewhere rg "ValueFormat[^a-zA-Z]"
77-88
: Update TypeScript types to reflect removed prop.The
value_format
prop has been removed and replaced with a hardcoded constant. Ensure that this prop is also removed from the component's TypeScript interface/type definitions.#!/bin/bash # Search for any remaining references to value_format in type definitions rg -t ts -t tsx "value_format.*interface|interface.*value_format|value_format.*type|type.*value_format"
230-230
: Verify uncontrolled component behavior.Changing from
value
todefaultValue
makes this an uncontrolled component. While this aligns with the PR objectives, please ensure that:
- No other components need to programmatically update this slider
- The component properly handles initial values and resets
✅ Verification successful
Based on the search results, I can see that the SliderView component is only used in a few specific places, primarily through schema configurations in JSON and as a type definition in Python. There are no direct references showing other components trying to programmatically update the slider's value. Additionally, the component is properly handling initial values through the
defaultValue
prop with fallback to[min, max]
.Change to uncontrolled component is safe to proceed
The codebase analysis shows no components attempting to programmatically control this slider's value after initial render, making the switch to an uncontrolled component using
defaultValue
appropriate and safe.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for components that might try to update this slider rg -A 5 "SliderView.*value.*="Length of output: 749
Script:
#!/bin/bash # Search for any references to SliderView component rg -A 5 "SliderView" # Search for any state updates or refs that might control the slider ast-grep --pattern 'const [$_] = useState($$$)' # Look for any parent components that might pass value props rg -A 5 "<SliderView.*value"Length of output: 12652
label="Min %" | ||
value={minText} | ||
onChange={(e) => handleInputChange(e, true)} | ||
onKeyDown={(e) => handleKeyDown(e, true)} | ||
UnitSelection={UnitSelection} | ||
UnitSelection={null} |
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.
🛠️ Refactor suggestion
Clean up unused unit-related code.
While the unit selection has been removed and labels hardcoded to "%", there's still unit-related logic that can be simplified:
- The
handleInputChange
function still handles both "%" and "flt" units - The
UnitSelection
component is defined but never used
Consider cleaning up the unused code:
const handleInputChange = (e, isMin: boolean) => {
const value = e.target.value;
if (!value) {
isMin ? setMinText("") : setMaxText("");
- } else if (unit === "%") {
+ } else {
const percentageValue = parseInt(value);
if (percentageValue >= 0 && percentageValue <= 100) {
isMin
? setMinText(percentageValue.toFixed())
: setMaxText(percentageValue.toFixed());
}
- } else {
- const floatValue = parseFloat(value);
- if (!Number.isNaN(floatValue)) {
- isMin ? setMinText(value) : setMaxText(value);
- }
}
};
Also applies to: 253-257
app/packages/core/src/plugins/SchemaIO/components/SliderView.tsx
Outdated
Show resolved
Hide resolved
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.
Left 2 comments about considering code for the future. I think it’s best we still give the Python Panel user the power when it comes to how the uniting looks. But if they choose %, we just render all the % options that are currently being hardcoded
Awesome LGTM |
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 (1)
app/packages/core/src/plugins/SchemaIO/components/DropdownView.tsx (1)
43-53
: Consider adding type safety and validation.
While the implementation is solid, consider these improvements:
- Add explicit type for the value parameter
- Validate separator when splitting/joining arrays
- const handleOnChange = useCallback(
- (value: any) => {
+ const handleOnChange = useCallback(
+ (value: string | string[]) => {
+ if (separator.length === 0) {
+ console.warn('Empty separator may cause unexpected behavior');
+ }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
- app/packages/core/src/plugins/SchemaIO/components/DropdownView.tsx (4 hunks)
- app/packages/core/src/plugins/SchemaIO/components/SliderView.tsx (5 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- app/packages/core/src/plugins/SchemaIO/components/SliderView.tsx
🧰 Additional context used
📓 Path-based instructions (1)
app/packages/core/src/plugins/SchemaIO/components/DropdownView.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 (3)
app/packages/core/src/plugins/SchemaIO/components/DropdownView.tsx (3)
2-2
: LGTM: Clean import and prop additions.
The changes follow React best practices with proper hook imports and clear prop defaults.
Also applies to: 36-36
55-62
: LGTM: Clean effect hook relocation.
The effect hook maintains proper organization while preserving the existing dynamic import logic.
203-207
: Verify click handler behavior with multi-select.
The current implementation might have these edge cases:
- Double event firing (onClick + onChange)
- Unexpected behavior with multi-select mode
Let's verify the multi-select behavior:
Consider this safer implementation:
onClick={() => {
if (addOnClickToMenuItems) {
+ if (multiple) {
+ // Handle multi-select case
+ const newValue = selected.includes(value)
+ ? selected.filter(v => v !== value)
+ : [...selected, value];
+ handleOnChange(newValue);
+ } else {
handleOnChange(value);
+ }
}
}}
LGTM |
What changes are proposed in this pull request?
How is this patch tested? If it is not, please explain why.
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
addOnClickToMenuItems
for immediate updates upon menu item selection.