fix(store): promote IncompatibleToggle to empty-state CTA when nothing matches (closes #355)#423
Conversation
…g matches Reported by @johny-mnemonic in discussion #312 — on his low-spec N100, the compatible-cards area was empty and the IncompatibleToggle sat at the bottom of an otherwise blank section. He didn't realise there was any filter at all. When compatibleCount === 0 the toggle now renders as a yellow alert card at the TOP of the area with explanatory copy + a Show all button, and the dimmed list opens by default. Subtle bottom-toggle behaviour preserved when there ARE compatible items above. Closes #355.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe ChangesIncompatibleToggle Empty-State UX
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
Code Review SummaryStatus: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Other Observations (not in diff)Issues found in unchanged code that cannot receive inline comments: Files Reviewed (2 files)
Fix these issues in Kilo Cloud Reviewed by grok-code-fast-1:optimized:free · 113,653 tokens |
| const [open, setOpen] = useState(false); | ||
| export function IncompatibleToggle({ count, compatibleCount = 1, children }: Props) { | ||
| const [open, setOpen] = useState(compatibleCount === 0); | ||
|
|
There was a problem hiding this comment.
WARNING: State 'open' is initialized based on 'compatibleCount' but does not update if the prop changes, potentially leading to incorrect initial state if 'compatibleCount' is updated dynamically. Consider using useEffect to synchronize the state with prop changes.
#425 (providers): the cloud-backend list inside the get-providers re-probe block was duplicated as an inline tuple even though CLOUD_TYPES is already defined as a module constant at line 22 and used elsewhere in the same file. Swap the inline tuple for the constant — same membership set, one source of truth, easier to extend. #423 (IncompatibleToggle): useState(compatibleCount === 0) only runs the initializer once. filtered.length / compatibleCount can transition to 0 *after* mount when the user changes the device filter, and the docstring on the prop says the toggle should auto-open in that case — but it didn't because the open state was frozen from mount-time. Added a useEffect that sets open=true when compatibleCount becomes 0. Only triggers on the 0 transition, so the user's explicit close-after-filter choice is preserved on the way back up. PR #418's bot finding was a false positive — mlc-llm/manifest.yaml already has type: service at line 3.
Closes #355 (johny on #312). When the compatible-cards section is empty, the previously-subtle IncompatibleToggle at the bottom of a blank pane was unfindable. Now it renders as a yellow alert card at the top with explanatory copy + opens the list by default, while preserving the subtle bottom-toggle behaviour when there ARE compatible items above. tsc -b clean.
Jay is asleep right now so this PR was opened by Claude Opus 4.7.
Summary by CodeRabbit
New Features