Consider changing Parser's switch cases to methods, for extensibility

[mitranim]

What pain point are you perceiving?

My use case seems to require special logic which cannot be done at the Renderer level, cannot be done by editing the AST via walkTokens (unless #2032 is implemented), but could be done at the Parser level if the API was easier to extend.

Describe the solution you'd like

In Parser, convert the bodies of switch cases to methods:

class Parser {
  parseToken(token, renderer) {
    switch (token.type) {
      case 'link': return this.link(token, renderer)
      case 'text': return this.text(token, renderer)

      // ...more cases for other known types; then:

      default: return this.default(token, renderer)
    }
  }

  link(token, renderer) {
    return renderer.link(token.href, token.title, this.parseInline(token.tokens, renderer))
  }

  text(token, renderer) {
    return renderer.text(token.text)
  }

  // ... more methods for other known types; then:

  default() {throw appropriate error}
}

We could even drop the switches and look up methods dynamically:

class Parser {
  parseToken(token, renderer) {
    if (this[token.type]) return this[token.type](token, renderer)
    return this.default(token, renderer)
  }
}

This would also make it trivial to implement #2032 in user code, by overriding default to support new token types.

Actual use case

To avoid an XY problem (proposing a poorly-chosen solution instead of stating the actual goal), here's what I actually need to do.

Depending on the source data:

• Sometimes links are treated as their child .tokens, ignoring href.
• Sometimes links are preserved as-is.
• Sometimes a text token is converted to multiple tokens including 0 to N links, unless it's already inside a link.

With this proposal, this logic could be implemented by subclassing Parser and overriding just the right methods:

class MdParser extends md.Parser {
  link() {/* just the stuff */}
  text() {/* just the stuff */}
}

[mitranim]

Addendum. For dynamic method lookup, we can avoid collisions with Object.prototype properties by extending null instead:

function Null() {}
Null.prototype = null

class Parser extends Null {}

console.log(Object.getOwnPropertyNames(Parser.prototype))
// ['constructor']

This gives us a squeaky-clean Parser.

[UziTech]

We have a proposal to add tokenizers and renderers to marked here. Maybe that would solve this problem.

[mitranim]

Thanks for pointing it out, I missed it. I still feel like both proposals are somewhat orthogonal, and this one could be done right now, while the other one is incubating. It doesn't seem to have as many design issues or performance issues. Even if it ends up being somewhat redundant, it would be quite handy for use cases like mine until #1872 is done (at some unspecified point). I might be able to PR it; let me know if I should try.

[UziTech]

We are always open to PRs. If it doesn't slow marked down it seems like something that would work.

You can test the speed changes by running npm run bench before and after the change.

[UziTech]

Custom tokenizers and renderer are available in v2.1.0

see Custom Extensions section in docs