tipus/editor/Editor.jsx

21 lines
446 B
React
Raw Normal View History

2024-06-14 01:24:07 +00:00
import { useState } from '@wordpress/element';
import { BlockEditorProvider } from '@wordpress/block-editor';
import BlockEditor from './BlockEditor';
import './editor.scss';
export default function Editor() {
Add inserter library as “secondary sidebar” 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]: https://github.com/WordPress/gutenberg/blob/de56874b51ee61e85c1b6a2348a6451682f9db54/packages/block-editor/src/components/inserter/stories/index.story.js [2]: https://github.com/WordPress/gutenberg/blob/f802107cb2a18ac9da3e87373c82f87207c9bc3d/platform-docs/docs/intro.md
2024-06-15 22:41:30 +00:00
const [ blocks, updateBlocks ] = useState([]);
2024-06-14 01:24:07 +00:00
Add inserter library as “secondary sidebar” 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]: https://github.com/WordPress/gutenberg/blob/de56874b51ee61e85c1b6a2348a6451682f9db54/packages/block-editor/src/components/inserter/stories/index.story.js [2]: https://github.com/WordPress/gutenberg/blob/f802107cb2a18ac9da3e87373c82f87207c9bc3d/platform-docs/docs/intro.md
2024-06-15 22:41:30 +00:00
return (
<BlockEditorProvider
value={ blocks }
onInput={ updateBlocks }
onChange={ updateBlocks }
>
<BlockEditor/>
</BlockEditorProvider>
);
2024-06-14 01:24:07 +00:00
}