Feature/382 refactor theme panel component

[snelsi]

Description

Main changes:

• Allow passing optional open and onOpenChange props to the ThemePanel component using the useControllableState hook
• Simplify setup by merging ThemePanel and ThemePanelImpl components. Remove redundant interfaces
• Move common logic related to hotkeys into a custom useHotKey hook (no external dependencies)
• Allow overriding default open/appearance hotkeys using optional openHotkey and toogleAppearanceHotkey props
• Allow passing null or false to disable a hotkey
• Hide the top-right open hotkey button when openHotkey is null

Things to improve in the future:

• Allow passing combination of keys like Control + F or Shift + H
• useHotKey implementation is very barebones. Consider using a library like react-hotkeys-hook

Testing steps

Use cases:

1. Controlled behaviour:

const [open, setOpen] = useState(false);

return <ThemePanel open={open} onOpenChange={setOpen} />

2. Custom hotkeys:

return <ThemePanel openHotkey="P" toogleAppearanceHotkey="/" />

3. Disabling hotkeys:

return <ThemePanel openHotkey={null} toogleAppearanceHotkey={false} />

Relates issues / PRs

Refs #382

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
themes-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 20, 2024 10:24am

[vladmoroz]

We wouldn't want to expose a way to customize the shortcut itself – the theme panel should always work the same in different places. Having different shortcuts on different websites is going to feel unpredictable.

Just a boolean prop to disable the shortcuts should be fine, e.g. disableShortcuts

[snelsi]

I respectfully disagree with your perspective. Default behavior can indeed remain consistent, but offering customization options allows users to adapt the component to fit seamlessly into their workflows. If a user chooses to change a defined hotkey, it should be within their responsibility, and providing such flexibility enhances the usability and adaptability of the library.

[snelsi]

By the way, just noticed that Radix Primitives has an example of Custom hotkey prop for Toast component 🙂

[chaance]

FWIW Radix Primitives is designed to be more flexible, where Themes is a more opinionated starter. I could be convinced on this, however. I agree it can be annoying to deal with potential conflicts.

[chaance]

Hi! Just wanted to weigh in here since we've had a little maintainer shuffle since this PR was opened.

Any chance we could break this into two separate, stacked PRs? I'd like to consider each new feature independently since there's a little unresolved feedback. Specifically it'd be nice to see it broken into three:

• Making ThemePanel use controllable state
• New useHotKey hook
• Allow for customizing/disabling hotkeys (and hiding the hotkey button accordingly)

I know it's been a while, so totally understand if you've moved on. Happy to take this as a feature request and re-implement if we decide to move forward.