This repository has been archived by the owner on Oct 16, 2023. It is now read-only.
Replies: 1 comment
-
The package export default compose(
withPluginContext,
applyWithSelect,
applyWithDispatch
)( PluginSidebarMoreMenuItem ); In the same way, we can extract the re-usable configuration shared by field blocks. The result is similar to the "concerns" ( For example, from the form builder: import defaultSettings from "./settings";
import {compose} from "@wordpress/compose";
const fieldBlock = {
"name": "give/my-field-block",
"settings": {
...defaultSettings,
}
}
export default compose(
applyWithNotMultiple,
)( fieldBlock ); The decorator can then spread additional settings onto the field block's configuration - for any number of field blocks. const applyWithNotMultiple = (config) => {
return {
...config,
settings: {
...config.settings,
supports: {
...config.supports,
multiple: false,
}
}
}
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I've been thinking through ways to extract this functionality for re-use, but don't yet have a solid direction.
And this discussion doesn't need to hold-up this current implementation, which I think is sufficient for now.
Related reading: https://jschof.com/gutenberg-blocks/sharing-functionality-between-gutenberg-blocks/
One idea is to use @wordpress/compose to, essentially, create traits or concerns that can be decorated onto a component. This would make it easy for a developer to apply these "traits" to a field/block.
This would also allow each "trait" to co-locate properties, functions, and JSX that are otherwise spread out across the component.
For example, the underlying field name logic is encapsulated in a hook (
useFieldNames
), but this still requires that each component using this hook connect the returned validator to the<InspectorControls>
's corresponding<TextControl>
. The logic and the control are in two different parts of the field's component.By contrast, a
withFieldName
Higher-Order Component (HOC) would encapsulate the logic and the control in a wrapper around the underlying field component.This is how Gutenberg shared functionality for Instance IDs.
It is also important to point out that Gutenberg has since deprecated a number of the HOCs in favor of hooks. Both HOCs and hooks are different methods to achieve a similar reuse of functionality and their use depends on the use case.
Beta Was this translation helpful? Give feedback.
All reactions