2024-06-15 00:01:22 +00:00
|
|
|
import { InterfaceSkeleton, FullscreenMode, ComplementaryArea } from '@wordpress/interface';
|
2024-06-14 16:04:59 +00:00
|
|
|
import { BlockBreadcrumb, BlockCanvas, store as blockEditorStore } from '@wordpress/block-editor';
|
Replace isolated-block-editor in favor of @wordpress/block-editor
Despite the fact that Gutenberg developers did not care at all about
uses of this library outside WordPress until last year[0], and that it
is almost impossible to do something that goes beyond the very basic
without using “private APIs”, they insist that the isolated block
editor should be “deprecated”[1].
I do not particularly care much about the isolated block editor, as it
_does_ use all these private APIs and, thus, it is very difficult to
use unless you use the exact same dependencies, otherwise it emits a
weird error regarding “unlocking” things that are not “locked” (i.e.,
the new-fangled way of “protecting” private APIs[2]). And,
apparently, things got easier with Gutenberg 18.5 with the
introduction of the BlockCanvas.
However, it is still a very frustrating experience, and the
documentation for most components and packages is next to
non-existent.
Nevertheless, i managed to get a barely functional editor that still
has some missing features, like the color of rich texts’ highlight
format[3], but it i believe it is a good base to grow the custom
editor on top of.
[0]: https://github.com/WordPress/gutenberg/issues/53874
[1]: https://github.com/WordPress/gutenberg/issues/57672#issuecomment-1883119040
[2]: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-private-apis/
[3]: https://github.com/WordPress/gutenberg/issues/55036
2024-06-14 01:24:07 +00:00
|
|
|
|
Add header with “pinned items”
I only wanted to have a button to open and close the sidebar, like
“regular” site editor does in WordPress. Apparently, this is done via
a “pinned” slot/fill thing, that make the visibility of that button a
user decision, by default—WordPress removes the pin button to avoid
that.
The thing is that it does not work: ComplementaryArea adds a
ComplementaryAreaToggle in the PinnedItems fill, and that toggle is a
button-like compenent that calls enableComplementaryArea or
disableComplementaryArea on the interface store, however
disableComplementaryArea does **not** update the interface store,
instead updates preferences, meaning that the useSelect inside the
toggle, that only subscribes to the interface store, is never called
when the area is disabled, and can not be enabled again with that
toggle button.
I worked around the issue by adding
dispatch({
type: 'ENABLE_COMPLEMENTARY_AREA',
scope,
area: undefined
});
at the end of disableComplementaryArea. I suspect this is not the
proper solution, and that there must be another way, because WordPress
does not exhibit that behaviour, however it signals that there _is_ an
error in the library, but i could not find any bug report within the
5k+ issues currently reported to Gutenberg’s project.
For now, it will do.
2024-06-15 01:40:14 +00:00
|
|
|
import Header from './Header';
|
2024-06-14 18:36:37 +00:00
|
|
|
import Sidebar from './Sidebar';
|
2024-06-15 00:01:22 +00:00
|
|
|
import { scope } from './constants';
|
2024-06-14 18:36:37 +00:00
|
|
|
|
Move the styles declaration inside BlockEditor
I do not know why, but when the styles are declared as settings of the
BlockEditorProvider, then typing anything is too slow to be usable.
But, when the styles are declared within the BlockEditor, without the
useSelect hook, then it works as expected (not fast, not that, but at
least not intolerably slow.)
I tried with a useMemo to keep the styles the same when there is no
change, which is most of the time, but the behaviour is the same.
Since i do not need to pass the styles from without the application,
at least not for now, my only option is to have them directly in
BlockEditor.
2024-06-15 21:28:58 +00:00
|
|
|
import blockLibraryCommon from '@wordpress/block-library/build-style/common.css?inline';
|
|
|
|
import blockLibraryEditor from '@wordpress/block-library/build-style/editor.css?inline';
|
|
|
|
import blockLibraryStyle from '@wordpress/block-library/build-style/style.css?inline';
|
|
|
|
import componentsStyle from '@wordpress/components/build-style/style.css?inline';
|
|
|
|
import formatLibraryStyle from '@wordpress/format-library/build-style/style.css?inline';
|
|
|
|
|
2024-06-14 17:41:17 +00:00
|
|
|
export default function BlockEditor() {
|
Move the styles declaration inside BlockEditor
I do not know why, but when the styles are declared as settings of the
BlockEditorProvider, then typing anything is too slow to be usable.
But, when the styles are declared within the BlockEditor, without the
useSelect hook, then it works as expected (not fast, not that, but at
least not intolerably slow.)
I tried with a useMemo to keep the styles the same when there is no
change, which is most of the time, but the behaviour is the same.
Since i do not need to pass the styles from without the application,
at least not for now, my only option is to have them directly in
BlockEditor.
2024-06-15 21:28:58 +00:00
|
|
|
const styles = [
|
|
|
|
{ css: componentsStyle },
|
|
|
|
{ css: blockLibraryCommon },
|
|
|
|
{ css: blockLibraryStyle },
|
|
|
|
{ css: blockLibraryEditor },
|
|
|
|
{ css: formatLibraryStyle },
|
|
|
|
];
|
2024-06-14 18:36:37 +00:00
|
|
|
|
2024-06-14 16:04:59 +00:00
|
|
|
return (
|
|
|
|
<>
|
|
|
|
<FullscreenMode isActive={ true } />
|
2024-06-14 18:36:37 +00:00
|
|
|
<Sidebar />
|
2024-06-14 16:04:59 +00:00
|
|
|
<InterfaceSkeleton
|
Add header with “pinned items”
I only wanted to have a button to open and close the sidebar, like
“regular” site editor does in WordPress. Apparently, this is done via
a “pinned” slot/fill thing, that make the visibility of that button a
user decision, by default—WordPress removes the pin button to avoid
that.
The thing is that it does not work: ComplementaryArea adds a
ComplementaryAreaToggle in the PinnedItems fill, and that toggle is a
button-like compenent that calls enableComplementaryArea or
disableComplementaryArea on the interface store, however
disableComplementaryArea does **not** update the interface store,
instead updates preferences, meaning that the useSelect inside the
toggle, that only subscribes to the interface store, is never called
when the area is disabled, and can not be enabled again with that
toggle button.
I worked around the issue by adding
dispatch({
type: 'ENABLE_COMPLEMENTARY_AREA',
scope,
area: undefined
});
at the end of disableComplementaryArea. I suspect this is not the
proper solution, and that there must be another way, because WordPress
does not exhibit that behaviour, however it signals that there _is_ an
error in the library, but i could not find any bug report within the
5k+ issues currently reported to Gutenberg’s project.
For now, it will do.
2024-06-15 01:40:14 +00:00
|
|
|
header={ <Header /> }
|
2024-06-14 16:04:59 +00:00
|
|
|
content={ <BlockCanvas height="100%" styles={styles} /> }
|
2024-06-15 00:01:22 +00:00
|
|
|
sidebar={ <ComplementaryArea.Slot scope={ scope } /> }
|
2024-06-14 16:04:59 +00:00
|
|
|
footer={ <BlockBreadcrumb /> }
|
|
|
|
/>
|
|
|
|
</>
|
|
|
|
);
|
Replace isolated-block-editor in favor of @wordpress/block-editor
Despite the fact that Gutenberg developers did not care at all about
uses of this library outside WordPress until last year[0], and that it
is almost impossible to do something that goes beyond the very basic
without using “private APIs”, they insist that the isolated block
editor should be “deprecated”[1].
I do not particularly care much about the isolated block editor, as it
_does_ use all these private APIs and, thus, it is very difficult to
use unless you use the exact same dependencies, otherwise it emits a
weird error regarding “unlocking” things that are not “locked” (i.e.,
the new-fangled way of “protecting” private APIs[2]). And,
apparently, things got easier with Gutenberg 18.5 with the
introduction of the BlockCanvas.
However, it is still a very frustrating experience, and the
documentation for most components and packages is next to
non-existent.
Nevertheless, i managed to get a barely functional editor that still
has some missing features, like the color of rich texts’ highlight
format[3], but it i believe it is a good base to grow the custom
editor on top of.
[0]: https://github.com/WordPress/gutenberg/issues/53874
[1]: https://github.com/WordPress/gutenberg/issues/57672#issuecomment-1883119040
[2]: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-private-apis/
[3]: https://github.com/WordPress/gutenberg/issues/55036
2024-06-14 01:24:07 +00:00
|
|
|
}
|