Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normalise falsely surrounds non void inline nodes #1948

Closed
RXminuS opened this issue Jul 2, 2018 · 5 comments
Closed

Normalise falsely surrounds non void inline nodes #1948

RXminuS opened this issue Jul 2, 2018 · 5 comments

Comments

@RXminuS
Copy link
Contributor

RXminuS commented Jul 2, 2018

I'm not sure if it's a bug, but the behaviour seems to deviate from the docs. In the docs it's suggested that only inlines that have isVoid must be surrounded by empty text nodes, but this normalisation function surrounds all inline nodes by text nodes.

if (child.object !== 'inline') return list

I can either make a PR to fix the issue by a simple

if (child.object !== 'inline' || !child.isVoid) return list;

or change the docs to clarify that every inline node needs to be surrounded by text nodes.

The reason this is important is that I wrote a performance critical "serialize" function that is supposed to output a perfect tree to avoid unnecessary normalisation, and this added a full 3 seconds to the loading time.

@ianstormtaylor
Copy link
Owner

Ah yeah, all inlines are surrounded by text nodes I guess.

@adamlibusa
Copy link

adamlibusa commented Dec 6, 2018

Ah yeah, all inlines are surrounded by text nodes I guess.

Why is this a thing? Is it a deliberate design decision or is it simply a consequence of the way Slate is implemented? Reading throughout other issues: Is it like that to fix the keyboard selection problem across multiple inlines (#1502)?

@yonahforst
Copy link
Contributor

@ianstormtaylor - I'm also curious if this is necessary for all inlines, or just void ones 😄

I have a large document with several hundred block nodes which I would like to convert to inline. All the insertions of empty text nodes causes the browser to hang.

I'm happy to submit a PR implementing what @RXminuS suggested above

@yonahforst
Copy link
Contributor

I'm struggling a bit trying to apply this rule to only void inlines. Here's the schema:

{
match: { object: 'inline' },
first: [{ object: 'block' }, { object: 'text' }],
last: [{ object: 'block' }, { object: 'text' }],
previous: [{ object: 'block' }, { object: 'text' }],
next: [{ object: 'block' }, { object: 'text' }],
normalize: (editor, error) => {
const { code, node, index } = error
const text = Text.create()
let i
if (code === 'first_child_object_invalid') {
i = 0
} else if (code === 'last_child_object_invalid') {
i = node.nodes.size
} else if (code === 'previous_sibling_object_invalid') {
i = index
} else if (code === 'next_sibling_object_invalid') {
i = index + 1
} else {
return
}
editor.insertNodeByKey(node.key, i, text)
},
},

What I can't figure out is how to tell the schema to match only when the inline is void.
If I add isVoid to the rule like so:

 { 
   isVoid: true,
   match: { object: 'inline' }, 
   first: [{ object: 'block' }, { object: 'text' }], 
   ...
}

that seems to tell the schema that the inline nodes must be void, otherwise they are invalid (instead of saying inline nodes that are void must match the following rules)

I also tried checking inside the normalize function if it's void and returning early, but it looks like the unless an operation is added to the editor, the default normalizer will run and the node will be removed.

So, I'm stuck 😅. I don't want to double my node count by adding a bunch of empty text nodes, but i also don't want to add the same number of setSelection commands just to get the rule to pass...

Any ideas? 🙏🏽

@ianstormtaylor
Copy link
Owner

I believe that this may be fixed by #3093, which has changed a lot of the logic in Slate and slate-react especially. I'm going to close this out, but as always, feel free to open a new issue if it persists for you. Thanks for understanding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants