fix: External HTML parse/export cases cont. #1998
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
@blocknote/ariakit
@blocknote/code-block
@blocknote/core
@blocknote/mantine
@blocknote/react
@blocknote/server-util
@blocknote/shadcn
@blocknote/xl-ai
@blocknote/xl-docx-exporter
@blocknote/xl-email-exporter
@blocknote/xl-multi-column
@blocknote/xl-odt-exporter
@blocknote/xl-pdf-exporter
commit: |
packages/core/src/extensions/Collaboration/schemaMigration/SchemaMigrationPlugin.ts
Outdated
Show resolved
Hide resolved
packages/core/src/extensions/Collaboration/schemaMigration/SchemaMigrationPlugin.ts
Outdated
Show resolved
Hide resolved
| // This plugin allows us to update collaboration YDocs whenever BlockNote's | ||
| // underlying ProseMirror schema changes. The plugin reads the current Yjs | ||
| // fragment and dispatches additional transactions to the ProseMirror state, in | ||
| // case things are found in the fragment that don't adhere to the editor schema | ||
| // and need to be fixed. These fixes are defined as `MigrationRule`s within the | ||
| // `migrationRules` directory. | ||
| export class SchemaMigrationPlugin extends BlockNoteExtension { |
There was a problem hiding this comment.
So, this handles the case where the attributes were stored in Y.js, what about if the user was using json or HTML as their storage?
There was a problem hiding this comment.
With JSON we don't need to change anything as the props field abstracts away having the prop attributes on blockContainer vs blockContent nodes.
With HTML, existing documents will indeed lose textColor/backgroundColor props when they get parsed under the new schema. However, we do explicitly state in the docs that you should use JSON for storing documents to the backend, and in general the use case of having HTML for document storage is not officially supported. So I don't think this is worth implementing. If it turns out there's demand for this then we can implement it. Unlike with the Yjs document migration, with HTML it can just be a simple function to transform the HTML string.
The more relevant HTML use case though is for static rendering, as we want old documents to still be displayed correctly with the new schema. Fortunately, the CSS changes in this PR are backwards compatible with the old schema, so this should be fine.
packages/core/src/extensions/Collaboration/schemaMigration/SchemaMigrationPlugin.ts
Outdated
Show resolved
Hide resolved
nperez0111
left a comment
nperez0111
left a comment
There was a problem hiding this comment.
I think it is fine to scope out the html migration
* WIP parse export fixes * Fixed color style parsing * Made default props get exported to inline styles in external HTML * Small fix * Updated snapshots * Updated snapshot * Updated e2e snaps * Fixed snapshot??? * fix: External HTML parse/export cases cont. (#1998) * Added plugin for collab schema migration * Moved color props to block content nodes * Fixed export for list items and updated unit test snapshots * Rename * Updated test snapshots * Implemented PR feedback * Fixed build
This PR continues the work from #1991, fixing parsing of
textColorandbackgroundColorprops. To do this, the attributes representing these props have been moved in the underlying ProseMirror schema fromblockContainernodes toblockContentnodes (e.g. paragraphs and headings). The reasoning for this can also be found in #1991.Because the ProseMirror has changed, existing collaborative documents lose any
textColorandbackgroundColorprops that were set, as the ProseMirror editor attempts to read the attributes from a different node to where they actually are. Therefore, theSchemaMigrationPluginhas been added, which updates existing collaborative documents to the new schema. This plugin runs whenever a collaborative document is initially loaded and traverses it. When it finds content that doesn't align with the editor schema, it can dispatch transactions to correct any issues caused by the mismatch between the document & editor schemas. Each correction is a separate piece of code that targets a specific change in the schema, and is called aMigrationRule. Currently, there is just oneMigrationRule, which moves thetextColorandbackgroundColorattributes as described above. Thanks to theMigrationRuledesign, it should be fairly easy to deal with any additional ProseMirror schema changes that we might have to make in the future.Besides these major changes, there are also a few minor ones:
lielements rather than their children.