While working on a feature based on your awesome work, I thought about saving the slug as part of the block.

When linking it, this would mean that even if you change the heading a little (for example, fixing spelling mistakes, adding parentheses, or something else), the link would not break.

The downside is that this could still leave unwanted or old headings in the anchor, but this could be fixed by just removing the block and creating a new heading. What do you think of this idea?

It's a great idea. We can create a random uuid. What do you think?

Oh, a UUID might be an option. But I think we should use the same slug generation that is used for pages.
Of course, this would make it harder to know where the link leads, but maybe we could do the same as we do for pages, where the slug is the ID and the name of the page, but the name is not important?

TLDR; I had the idea for mention links (so that you can select a anchor with a mention). It's working quite good: Vito0912@f551cf4. So maybe also something to pick up. Not sure if I ever will make a PR with it, as it will definitly be slower when having many many pages (due to content) and I have it as a part of customized version of your PR with faster scrolling (on loading) and moved the anchor item to not change the layout on hover: Vito0912@4d85f83 (but it has it's own flaws - like weird behaviour in edit mode)
And for this static slugs for anchors would be great. Because then the mentions would be a LOT more stable. So that was my intention with asking

Edit: Corrected "mention links"

The tiptap UniqueID extension is now open source.
We can use it to attribute IDs to the heading tags.
Ideally, we should use nanoid instead of the default UUID generation.
This will make the URLs much cleaner.

I would also choose nanoId. I think it is already used for the page ID? The main benefit is that it makes copying easier, because some browsers do not copy the dash when you double tap.

So would you be ok with storing a uid (nanoid) with the headers (to make anchors more stable) potentially with your named extension?

So would you be ok with storing a uid (nanoid) with the headers

The Unique ID extension does that already, so we can go with it.

I created a PoC for this. https://github.com/Vito0912/forkmost/tree/feat/anchorStatic
It uses nanoId for the id. I am not sure how important this is https://tiptap.dev/docs/editor/extensions/functionality/uniqueid#filtertransaction since I have not really worked with tiptap.

Sadly it only seems to work in the editor and not for shared pages. There the ID is not stable. So it looks like that we still need to extend the header by an id and save it to the db - which I thought this would do?

The format now uses the old slug system with -<uid> added at the end. However, only the uid is needed for scrolling - Like for pages.

Maybe we can also make the scrolling better? I used an observer in on of my other branches, but it did not work that well in edit mode. When the editor switches from read to edit mode (connects), the scroll action gets reset mid scrolling.

@Vito0912 I merged your changes. I rewrite the url with the current "id" window.history.replaceState(null, "", `#${el.id}`);

In shared pages the anchors are not working correctly because of this line page.content = await this.updatePublicAttachments(page); in share.service.ts, I'll check as soon as possible

Thank you very much! Your idea with #${el.id} I think is very very good!

In shared pages the anchors are not working correctly because of this line page.content = await this.updatePublicAttachments(page); in share.service.ts, I'll check as soon as possible

Thank you for the information. Would have never guessed that tbh. If you have time and are ok with it, could you explain why this happens? Is it just because of the conversion in between? Also, to avoid spamming here, if you use Discord, you can contact me at vito0912 so we can stay in touch. I hope to contribute some PRs in the future and .

One more thing: In the future, could you please merge these changes by creating a PR to your repo [Or I can do - Just thought that my commit was to unfinished because of the shared pages not working]? This way, the commit history stays clean and there are no potential merge conflicts.

I fix the issue in shared pages. I updated the extensions schema server side in collaboration.utils.ts

Shouldn't collaboration.utils.ts also handle nanoId generation (instead of uuid) in case someone views a shared page before editing it with the editor so a uuid would be asigned - or do I mix something up completely?

Shouldn't collaboration.utils.ts also handle nanoId generation (instead of uuid) in case someone views a shared page before editing it with the editor so a uuid would be asigned - or do I mix something up completely?

Shared pages only fetch content, they are read-only and don't have any realtime updates. Therefore collaboration.utils.ts simply requires a schema