Name agnostic implementations

[holtwick]

I'm currently using my own node names in my project, like p instead of paragraph. This is because for JSON serialization without any further compression everything bloats up with those long names.

It works fine. I usually subclass TipTap's implementations and override the name getter property.

So what I'm asking for is: would it be possible to use the name property consistently, like in this example by adding a type or name attribute to the function?

https://github.com/scrumpy/tiptap/blob/59d37f569726d9af450b315e8011bb8f1022c57c/packages/tiptap-extensions/src/nodes/CodeBlockHighlight.js#L11

I understand that this does not make much sense for complex ProseMirror based routines, like tables or nested lists, but for those simple ones it should be straight forward.

[philippkuehn]

@holtwick Yeah, that makes totally sense! It's a bit messy right now. Will fix that.

What do you think of this idea?

[holtwick]

Well, I guess sub-classing is sufficient. I also wonder, if that additional logic described in #123 isn't to much overhead.

Here an example from my code:

import {Heading} from 'tiptap-extensions'
import names from '../names'

export default class HeadingExt extends Heading {
  get name() {
    return names.h
  } 
}

[philippkuehn]

Ok, yeah maybe you're right. That really doesn't seem to be an effort to extend existing classes.

Back to topic: I released a new version for tiptap-extensions.

But there are still some limitations. What about the content option for lists? If you want to overwrite the name of ListItem you have to overwrite the complete schema of todo_list.

// BulletList extension
get schema() {
  return {
    content: 'list_item+',
    group: 'block',
    parseDOM: [
      { tag: 'ul' },
    ],
    toDOM: () => ['ul', 0],
  }
}

It's the same issue for commands. There are some toggle commands you have to overwrite.

// Blockquote extension
commands({ type, schema }) {
  return () => toggleWrap(type, schema.nodes.paragraph)
}

[holtwick]

Indeed, this is tricky. Maybe this task should be left to the user, because this goes deep into structural decisions. In my code e.g. I have a custom list implementation (see #166) and I also avoid blockquote completely.

But if that problem you describe needs to be solved in a generic way I guess you'll need to add those options you mentioned before on editor setup. A mapping from the common names to custom names might be the most straight forward solution, like:

    // ...
    typeNameMap: {
         'list_item': 'li',

Each Node implementation gets those via constructor and can fix the get name accordingly.