-
-
Notifications
You must be signed in to change notification settings - Fork 22
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
Allow options to override default node types and mark types #31
Comments
Hi, @dylans. Yes. I thought it may be needed if someone use this seriously. Thank you! This plugin trusts mdast data structure (the type definition in this plugin is bit outdated but almost the same). |
Thanks @inokawa , I'll put something together soon and get your feedback. |
ok, I finally have something as a starting point for discussion (the code itself is far from efficient and should at least illustrate the concept): master...dylans:ast-custom-tags (obviously it would be much better to decide on a pattern to override the default ast type with the parameters passed in more efficiently than what I've done here, but it would also be ideal to preserve roughly the same defaults structure people might use in configuring slate or slate-plugins. Please have a look, let me know if you have thoughts or feedback. I'm also happy to discuss it in real-time if that's easier. :) |
It's also an entirely reasonable thing to say that maybe this should instead be a separate ast step, e.g. slate ast -> customized slate ast. |
Thank you @dylans. Please point out if you think I misunderstood. If so that is because of my English skills... This lib handles The mdast ast suports all markdown syntax and it is documented, and there are no default slate structure because it is customizable. I come up with passing use(remarkToSlate, {
heading: (mdast, createChildren) => ({
type: mdast.type,
[mdast.depth]: true,
children: createChildren(mdast.children),
}),
paragraph: (mdast, createChildren) => ({
...
})
}); |
Thanks @inokawa , I agree. I think the more I tried to force things the way I did, the more I didn’t like the approach I took. slate-plugins and remark-slate follow the approach I proposed but it really is cumbersome to manage so I think I like your suggested approach. I’ll think about it more in the morning and let you know if I have further thoughts. |
I also prefer this library to |
Hi, @siliconeidolon . Add new feature to handle unknown nodes to this plugin is possible, but probably harder to achieve. |
@inokawa Thanks for responding. So, I should first process my slate content to look for my custom mark (eg: underline) and then run slateToRemark?
preprocessedSlateContent:
serializedContent: This almost works, but I wonder where the escape characters are coming from? |
I added This is initial support of custom AST and may have some problems. |
Thanks for adding this. It could potentially make my de/serialisation functions a lot simpler! |
I had the same problem with back slashes. If someone is looking for a solution, here's mine. const value = [{
type: 'paragraph',
children: [
{ text: 'This text is underlined.', underline: true },
],
}];
const processor = unified()
.use(slateToRemark, {
overrides: {
paragraph: (node, next) => {
const children = node.children.map(child => {
if (child.text && child.underline) {
const { text, ...modifiedChild } = child;
return {
...modifiedChild,
type: 'html',
children: [ { text: `<u>${child.text}</u>` }]
}
}
return child;
});
return ({
type: "paragraph",
children: next(children),
});
},
},})
.use(stringify);
const ast = processor.runSync({
type: "root",
children: value,
});
const mdText = processor.stringify(ast);
console.log(mdText);
// <u>This text is underlined.</u> |
@vavilov2212 Hey, does that above work for you in the latest version of the plugin? I'm having issues with Update: figured it out finally by digging into the slateToRemark source. My overrides for slateToRemark can't be exactly the same as remarkToSlate because I'm overriding the Why am I doing this? because I'm using Slate with Plate and for some reason, Plate uses different names for the types (which is pretty annoying). So for example: .use(slateToRemark, {
overrides: {
p: (node: any, next: any) => ({
type: 'paragraph',
depth: node.depth,
// You have to call next if the node has children
children: next(node.children),
})
}
}) .use(remarkToSlate, {
// If you use TypeScript, install `@types/mdast` for autocomplete.
overrides: {
paragraph: (node: any, next:any) => ({
type: 'p',
depth: node.depth,
// You have to call next if the node has children
children: next(node.children),
})
}
}) |
Is overriding nodes like inlineCode and strong supported? if so can you give an example. I need to go from inlineCode=true to code=true |
@janaka |
Have you considered allowing a second parameter to support custom node types and mark types within an AST?
I'm trying to decide between remark-slate and remark-slate-transformer. This package handles a far more comprehensive set of markdown but would require an additional step of parsing from Slate to the AST we store which uses custom node types.
I'm happy to contribute a PR if this is a feature you'd like to add, just respond here or find me on the Slate slack group.
The text was updated successfully, but these errors were encountered: