I am honestly starting to believe that i am already dead and
everything i do is my punishment in hell.
All i wanted is to have the list of blocks that i can insert on the
editor’s right side, like WordPress does. At first i believed it was
a simple task, judging from the snipped at Gutenberg’s Storybook[0]:
() => {
const wrapperStyle = {
margin: '24px',
height: 400,
border: '1px solid #f3f3f3',
display: 'inline-block'
};
return <ExperimentalBlockEditorProvider>
<div style={wrapperStyle}>
<BlockLibrary showInserterHelpPanel />
</div>
</ExperimentalBlockEditorProvider>;
}
See? Easy! Except that they are using a
ExperimentalBlockEditorProvider, without telling us why—is it
necessary for BlockLibrary to work?—, that seems to be a private
component; and BlockLibrary, that is a component that apparently does
not exist. Where is it? How knows! There is no import in the
Storybook’s snippets; why would there be any?
As it turns out[1], that BlockLibrary is a component of
@wordpress/block-editor’s inserter component, and it is
private. Great! What i am supposed to do, now? Lie and tell them i am
part of WordPress so that i can call unlock? “Fortunately”, as it
were, this component is also exported in the old-fashioned way, with
the __experimental prefix.
Let’s move on.
The issue was that when the BlockLibrary is visible, Gutenberg’s
performance slows to a crawl: i can type at about one key per second,
if that many. Completely unusable, even with the styles hard coded
inside BlockEditor, meaning the error was elsewhere, but i did not
know where.
To try to figure this out, i started a new project following to the
letter their “Getting Started” document[2]; no styles, no interface,
nothing. That done, i then added the BlockLibrary next to
BlockCanvas, to check if the problem was just having that component
all the time visible, something that WordPress doesn’t do—it closes
the library when trying to edit the document—, with encouraging
results: no sluggishness. Wonderful! It is something i did wrong,
which means it is something i can fix.
I kept adding more and more components, trying each time whether the
performance issue was back, until i had all the files in the new, test,
project exactly, byte by byte, like the files of this project,
including HTML and style files. However, npm run dev inside that
project, everything was fine; npm run dev here, i would have died
before writing this commit message at that speed.
I could not explain the difference other than blaming the dependencies.
I checked package.json, and sure enough there have been a new release
of Gutenberg like four hours ago, only five days after the release
of 18.5.
Of course.
“No problem,” i said to myself. “Copy package.json over here, remove
package-lock.json and node_modules, and npm install again.” And so i
did. And now the application was behaving different: it would not
start.
I got a bunch of error messages like this:
Uncaught TypeError: (intermediate value)(...) is undefined
BlockTools index.js:76
React 12
workLoop scheduler.development.js:266
flushWork scheduler.development.js:239
performWorkUntilDeadline scheduler.development.js:533
js scheduler.development.js:571
js scheduler.development.js:633
__require2 chunk-MWY3P57A.js:21
js index.js:6
__require2 chunk-MWY3P57A.js:21
React 2
__require2 chunk-MWY3P57A.js:21
js React
__require2 chunk-MWY3P57A.js:21
<anonymous> react-platform.js:11
I then copied package-lock.json over the new project, npm ci, and the
application would start, but it was slow too. So, it **was**
dependency-related, but now i had another problem: even with the same
package.json and package-lock.json files, running npm update would
render the application unable to start with the same error messages as
above.
Notice that i had not specified my versions with a caret; i was
telling npm that i wanted these versions, and no other but the
versions i had been using up until now. My guess is that some
transitive dependency has been updated, it is specified with the caret
or some other way, and has a regression or change that does not follow
semantic versioning.
The situation was, then, that i had a performance issue with Gutenberg
whose source was one of the 394 packages installed in node_modules,
therefore i could not fix it in my application, but i could not update
dependencies either, because then i had some incompatibility between
versions, and the application would not start.
I had no other option than to update Gutenberg too, and that fixed
both the incompatibility and performance issues, but has left a very
bitter taste in my mouth, and i am wondering if using Gutenberg, or
any React-based library, is the way forward: too complex, with too
many couplings, and very, very brittle.
[0]: https://wordpress.github.io/gutenberg/?path=/story/blockeditor-inserter--library-without-patterns
[1]: de56874b51/packages/block-editor/src/components/inserter/stories/index.story.js
[2]: f802107cb2/platform-docs/docs/intro.md
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.
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.
It makes more sense, i believe, to enable the sidebar complementary
area from within the sidebar component, as this is called when the
component is included in the hierarchy.
I also moved the scope string to a constants file, so i can find where
it is used with code analysis instead of relaying on grep.
I want this only to later on show the sidebars with the inserter and
inspector, but for now, since i do not understand yet how i am
supposed to use ComplementaryArea, i add the interface with the
breadcrumb at the bottom.
The FullscreenMode block is to “cancel out” the 160px margin on the
left, and 32px on the top, that @wordpress/interface’s style add by
default.
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
Gutenberg uses its own @wordpress/i18n for internationalization, which
is not much more than a wrapper around tannin[0], a reimplementation of
Jed[1].
It uses the same brain-damaged idea of all JavaScript applications: load
a really huge JavaScript object with the source text as key, and the
translations, if there are plurals, as values. That is what they call
“a gettext localization library”.
The problem now becomes: how do i extract the translatable strings from
the libraries?
Isolated Block Editor’s maintainer stance is very clear: “It’s
Gutenberg, so whatever you need to do there will work the same”[2]. In
other words, “don’t know; don’t care”.
Let’s see what Gutenberg people say.
Well, Gutenberg may not require WordPress, but their developers sure
assume that you are using WordPress[3], and if you complain then their
response is “Why do you think using wp-cli is not easy enough?”[4].
Apparently, before wp-cli they used @wordpress/babel-plugin-makepot,
that creates a POT file for each JavasScript processed with WebPack,
but does not extract the strings from imported packages. Which is kind
of logical, but then where do i get the required JSON files i need to
load to translate their fucking overly complex piece of crap?
Or, said in another way, how does WordPress do it? Apparently, they do
the same they do for every other plugin[5]: with GlotPress[6].
That _would_ work if i used the exact same versions as the plugin does,
but it would not help me translate the strings from
@automattic/isolated-block-editor because they are **not** a WordPress
plugin. And, as we saw previously, the maintainer does not care.
Well, i have to extract them myself somehow. Using the uglies hack i
could muster, apparently, because wp-cli i18n refuses to extract strings
from inside node_modules: create a symlink from each source directory i
need to translate into my po folder, and use their beloved wp-cli i18n
to create the po, including the strings from my source.
Then i downloaded the plugin PO file to include the official translation
to Spanish, and wrote a couple to test whether these from Isolated Block
Editor were being correctly extracted.
However, i can **not** use wp-cli i18n to generate the JSON file because
the fucking thing wants to generate a single JSON file for each
JavaScript source file, thus generates around 650 JSON files.
Are we mad?!
The author of Jed recommends po2json and at this point i do not really
care if i need yet another fucking tool for this. Just do it, but make
sure it is Jed’s 1.x version, otherwise “modern” Gutenberg does not know
what to do with the translations.
What a shitshow.
[0]: https://github.com/aduth/tannin
[1]: https://github.com/messageformat/Jed.
[2]: https://github.com/Automattic/isolated-block-editor/issues/195#issuecomment-1359566724
[3]: https://github.com/WordPress/gutenberg/issues/14803#issuecomment-479823416
[4]: https://github.com/WordPress/gutenberg/issues/14803#issuecomment-479581903
[5]: https://github.com/WordPress/gutenberg/issues/13535#issuecomment-458678681
[6]: https://developer.wordpress.org/block-editor/contributors/localizing/
It is just a test to see whether the block editor loads, because it is
not so easy: it requires specific versions of the dependencies, or it
will fail with some idiotic syntax errors after failing to “convert” the
libraries code.
And it is impossible to use with Vite: it refuses to accept incorrect
SCSS code, that WordPress has a lot of, with things as `::after::after`.
What i did is write my package.json, replace the generated lock file
with the one from Isolated Block Editor, and npm install again, to
“clean up” the lock file.
jordi fita mas