Parse custom links defined in inlineContentSpec

[JSHSJ]

Is your feature request related to a problem? Please describe.
We have a custom link type, called a reference. I tried creating a custom inline content spec for it, but the parse function never gets elements with tagName === "A". I assume they are parsed by the built-in link inline content before.

• Is there a way to change the parsing priority?
• (additional) is there a way to use one of the Toolbars to detect custom nodes? The LinkToobar only detects URLs, which is not unique in our case.

Describe the solution you'd like
Allow adding a parsing priority, either through their position in BlockNoteSchema.create or in createReactInlineContentSpec, so I can parse custom links.

Describe alternatives you've considered
Of course it might be possible by wrapping the component in a span, but that is not what we want ideally. We're coming from TipTap, so I might try adding it as TipTap Extension, but I prefer your way of defining custom content.

[nperez0111]

Is there a way to change the parsing priority?

The runsBefore is just for this, it is part of the second argument of createInlineContentSpec, which we seem to not have updated the documentation for here: https://www.blocknotejs.org/docs/features/custom-schemas/custom-inline-content#inline-content-implementation-reactcustominlinecontentimplementation

Links are treated pretty oddly in BlockNote though (since they are still in the Tiptap API, not the BlockNote one), so I think you may run into some issues actually setting a priority that is high enough, they seem to set it to be really high by default: https://github.com/ueberdosis/tiptap/blob/35645d94ae9cd73448a564104c2e08f64e9564bc/packages/extension-link/src/link.ts#L197 I think I will change this on the BlockNote side to be set to the same priority as the other default extensions to make it easy for you to override

This conversation is likely to be useful in helping understand how we would go about links in BlockNote: #1861

As for the LinkToolbar, it is built only for our links and to make it do more than that would be complicated and not likely to work well. So I'd recommend just re-implementing this for yourself, perhaps you can use our implementation as reference for it.

[JSHSJ]

Hey @nperez0111,

thanks for your timely response. I tried adding ["link", "text"] to runsBefore, but that didn't seem to have the effect I was hoping for. Is there another property I can test?

I'll give you my complete custom schema for context:

export const InternalReference = createReactInlineContentSpec(
    {
        type: 'internalReference',
        propSchema: {
            // uuid of the referenced document element
            id: {
                default: 'unknown-id',
            },
            // Type of document element, e.g. 'user'
            referenceType: {
                default: 'unknown',
            },
            // Attribute of the referenced document element to show as label
            referenceAttribute: {
                default: 'title',
            },
            // Style of the reference, i.e. 'reference' or 'inline'
            referenceStyle: {
                default: 'reference',
            },
            displayName: {
                default: 'Unknown',
            },
            shouldFetchProperties: {
                default: false,
            },
        },
        content: 'none',
    } as const,
    {
        render: props => (
            <InternalReferenceRenderer
                id={props.inlineContent.props.id}
                type={props.inlineContent.props.referenceType as InternalReferenceTypes}
                displayedAttribute={props.inlineContent.props.referenceAttribute as InternalReferenceAttributeNames}
                shouldFetchProperties={props.inlineContent.props.shouldFetchProperties}
                elementAttributes={{} as InternalReferenceElementAttributes}
                displayStyle={props.inlineContent.props.referenceStyle as ReferenceDisplayStyles}
                onUpdate={update => {
                    console.log(update);
                }}
            />
        ),
        parse: element => {
            const isInternalReference =
                element.tagName === 'A' && element.className.includes(internalReferenceClassName);

            console.log('Parsing element for InternalReference:', element, 'isInternalReference:', isInternalReference);

            if (!isInternalReference) {
                return undefined;
            }

            return {
                type: 'internalReference',
                props: {
                    id: element.dataset['internal-reference-id'] || 'unknown-id',
                    referenceType: element.dataset['internal-reference-type'] || 'unknown',
                    referenceAttribute: element.dataset['internal-reference-attribute'] || 'title',
                    referenceStyle: element.dataset['internal-reference-style'] || 'reference',
                    displayName: element.textContent || 'Internal Reference',
                    // parsed elements should check if update is needed
                    shouldFetchProperties: true,
                },
            };
        },
        toExternalHTML(props) {
            const { id, displayName, referenceType, referenceStyle, referenceAttribute } = props.inlineContent.props;

            const icon = InternalReferenceIconByType[referenceType as keyof typeof InternalReferenceIconByType];

            return (
                <a
                    className={internalReferenceClassName}
                    href={getLinkToHandbookElement(id, false)}
                    target="_blank"
                    data-internal-reference-type={referenceType}
                    data-internal-reference-id={id}
                    data-internal-reference-attribute={referenceAttribute}
                    data-internal-reference-style={referenceStyle}
                >
                    <i className={`${icon.variant} fa-${icon.name}`} />
                    {displayName || 'Internal Reference'}
                </a>
            );
        },
        runsBefore: ['link', 'text'],
    },
);

It's quite a complex component, that will later have to refetch and update its own data, but I think through the update function that should hopefully work just fine. The log in my parse function never logs any links, unfortunately.

I've read through the issue about link, which seems to be sort of my direction, but not quite.

On the toolbars:
I think once parsing my custom links works fine, I can maybe work with const { getLinkAtSelection } = useExtension(LinkToolbarExtension); that API to detect in inside the toolbar. We'll see.

Is there a way to create a custom toolbar for a specific extension? I found the Component.Generic.Popover which works great for nested menus, but I'll need the initial "open me when it's an external extension" similar to how the LinkToolbar works.

Thank you so much!

[nperez0111]

thanks for your timely response. I tried adding ["link", "text"] to runsBefore, but that didn't seem to have the effect I was hoping for. Is there another property I can test?

@JSHSJ, like I said, the link extension is in the Tiptap layer, so this would have no effect, I'm just pointing out that there is a mechanism for this, we are just partway through the migration.

I think once parsing my custom links works fine, I can maybe work with const { getLinkAtSelection } = useExtension(LinkToolbarExtension); that API to detect in inside the toolbar. We'll see.

You'll likely need to re-implement this extension, since it is meant for our extension, and therefore only looks for marks named "link", and we wouldn't change that.

Is there a way to create a custom toolbar for a specific extension? I found the Component.Generic.Popover which works great for nested menus, but I'll need the initial "open me when it's an external extension" similar to how the LinkToolbar works.

You'll need to re-implement what the LinkToolbar does to have the same functionality. In the future we may want to make an API that does this better, but we don't need it at this time for anything than the LinkToolbar, so we don't have an idea of what a good abstraction for this would be.

I don't think we would be able to do anything about this in the short term, since it will be a larger refactor to get this to work. You can take a look at the suggestion I made here, and put up a PR with your solution if you need to implement it quickly.

The suggestion in the other issue is sort of what you are already doing, but to instead model it as a different piece of content instead of as a link. Like just set your export and parse to use a wrapping div instead or something, so it is not in conflict with the link extension.

Setting the priority of the link extension to 100, should cause the default priority of your custom extension to be higher (since they default to 101), but I am not sure that this is the approach that I want for the long run which is why I only put up a draft PR

[JSHSJ]

Thank you very much for your suggestions and the quick actions. I'll see if I can find the time to follow through with your suggestion.

Wrapping my extension's element in a

would certainly be the easiest way forward, but would require us to migrate all existing links made in our old TipTap editor in some way. I had hoped that would be possible through a parse function, but I understand the issues and welcome your idea of getting rid of the TipTap + linkify implementation :)

[nperez0111]

Thanks for your understanding @JSHSJ, perhaps you can have an intermediate parse step that turns the a tag into something else if it matches your expected format.

I will keep this open given that links are difficult to customize at this point

[JSHSJ]

Writing a "pre" parse function did address the issue, thank you!

When trying to write a custom ToolbarController I had difficulties checking whether my custom inline node is selected. My node is not editable (as in text editable) but should have a toolbar.

I believe your LocationAPI implementation in #2044 will address that issue, and allow me to check if my current node is selected, right?

Thank you very much!

[nperez0111]

The location API would probably make that sort of thing easier.

For now though, I'd recommend you look at how the linkToolbar works to see how we'd approach it. You can have a BlockNote Extension which has a store which holds whether the current selection is pointing to the node that you want, and then choose to render a menu based on that.

Also, another approach is to have a click handler within the custom node's element and then trigger a toolbar based on that.

We want to make better APIs for this sort of thing in the future, but the only elements that we have that need this sort of menu are links right now so we felt like we didn't have the right abstraction to recommend to people.

What is the custom node you are trying to make?

What are you building with BlockNote, btw?