[FEATURE] Dynamic Color Picker Component

[GeoffDusome]

What does this do/fix?

This pull request refactors the color picker functionality across multiple components to use a new reusable DynamicColorPicker component, improving code maintainability and user experience. It removes custom color grid implementations and legacy modal-based color pickers, streamlining color selection in both the Icon Picker and Image Overlay Card blocks. Additionally, it updates import paths for consistency and cleans up related CSS.

Color Picker Refactoring

• Added a new reusable DynamicColorPicker component that leverages WordPress's ColorPalette and theme color settings, supporting opacity and transparent options. (wp-content/themes/core/assets/js/components/DynamicColorPicker.js)
• Refactored the Icon Picker to use DynamicColorPicker for both icon and background color selection, replacing the custom color grid implementation. (wp-content/themes/core/assets/js/components/IconPicker.js) [1] [2] [3]
• Updated the Image Overlay Card block to use DynamicColorPicker for overlay color selection, removing the modal and legacy ColorPicker usage. (wp-content/themes/core/blocks/tribe/image-overlay-card/edit.js) [1] [2] [3] [4] [5]

Codebase Consistency

• Updated import paths for IconPicker and related utilities to reflect their new locations, ensuring consistency across blocks. (wp-content/themes/core/blocks/tribe/icon-card/edit.js, wp-content/themes/core/blocks/tribe/icon-picker/edit.js) [1] [2]

CSS Cleanup

• Removed legacy CSS for the custom color grid in the Icon Picker, as it is no longer needed with the adoption of DynamicColorPicker. (wp-content/themes/core/blocks/tribe/icon-picker/editor.pcss)
• Minor formatting improvements to tab styles in the Icon Picker CSS for consistency. (wp-content/themes/core/blocks/tribe/icon-picker/editor.pcss)

QA

Screenshots/video:

• Link to Video

[spadilha]

🟢 I loved it @geoff. Like I mentioned to you, I’m using and in the GUQ project and I think their UI is much cleaner and easier to use. One caveat is that we can’t hide the color picker when we want to restrict the selection to a predefined list. The only workaround I found was hiding it with CSS.

That said, it might be worth extending DynamicColorPicker in the near future to support GradientPicker as well. Maybe even auto-hide the picker UI when a specific class is present on the control. Just a thought.

Nice work. 🌮

[dpellenwood]

🍏 I'm good with this. Note that @MlKilderkin is also working on a color picker setting via ACF for storing as an option or setting meta value. It might be good for you to collab with him and see if we can standardize a picker UI for all these cases.

[MlKilderkin]

@GeoffDusome is that just a block? Or we can re-use this everywhere? E.g use color picker on settings, acf based blocks, page attributes?

[GeoffDusome]

@dpellenwood @MlKilderkin This is a reusable component only meant for use with non-ACF blocks. We wouldn't be able to use this with ACF blocks at all and any experience we create with ACF would need to be completely different based on the controls available to us via ACF. Of course, we could create our own experience to save color data as needed using custom controls, but I don't think using a react component for this would go very well outside of the block editor controls. In fact, I'm not even sure you can use WP components outside of a block context. If you can, I'm not even sure how.

Typically though, when we're adding page-level or option-level settings to WP we're doing it via ACF.

I don't see why using a combination of the Color Picker and some sort of swatch based picker (grabbing the color options from theme.json) would be out of the question for ACF though. The controls would have to work together and override each other, which would I think require some custom JS or maybe both the swatches & custom picker both return values and one just overrides the other? Not sure.

IMO the ACF experience is totally different and I wouldn't expect the experiences to be the same if I were a user but that's just me.

[MlKilderkin]

@dpellenwood @MlKilderkin This is a reusable component only meant for use with non-ACF blocks. We wouldn't be able to use this with ACF blocks at all and any experience we create with ACF would need to be completely different based on the controls available to us via ACF. Of course, we could create our own experience to save color data as needed using custom controls, but I don't think using a react component for this would go very well outside of the block editor controls. In fact, I'm not even sure you can use WP components outside of a block context. If you can, I'm not even sure how.

Typically though, when we're adding page-level or option-level settings to WP we're doing it via ACF.

I don't see why using a combination of the Color Picker and some sort of swatch based picker (grabbing the color options from theme.json) would be out of the question for ACF though. The controls would have to work together and override each other, which would I think require some custom JS or maybe both the swatches & custom picker both return values and one just overrides the other? Not sure.

IMO the ACF experience is totally different and I wouldn't expect the experiences to be the same if I were a user but that's just me.

No problem with that. @dpellenwood I think we can still use mine approach since it adds custom picker based on ACF as ACF field. I'll cleanup PR from test data but it will work for ACF
@GeoffDusome do you mind to take a look on it? It still in progress but it also uses theme.json for colors