Expose defaultHandlers to be reused

[JounQin]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

Maybe a bit similar to syntax-tree/mdast-util-to-markdown#34

I'm trying to implement a tiny util cf2md which Transform from confluence flavored HTML to Markdown with enhanced features.

In confluence's HTML, pre can be used without code inside, so I have to wrap its direct text nodes into a code node to reuse original h.handlers.pre, but there is no defaultHandlers provided, so I have to use import { code } from 'hast-util-to-mdast/lib/handlers/code.js' which is the original h.handlers.pre actually.

import { code } from 'hast-util-to-mdast/lib/handlers/code.js'

unified()
  // ...
  .use(rehypeRemark, {
    handlers: {
      pre(h, node, parent) {
        // I'd like to have `h.defaultHandlers.pre` here
        return code(h, {
          ...node,
          children: node.children.map(child =>
            child.type === 'text'
              ? {
                  type: 'element',
                  tagName: 'code',
                  children: [child],
                }
              : child,
          ),
        })
      },
    },
  })

See also https://github.com/rx-ts/cf2md/blob/main/src/index.ts#L82

Solution

Expose defaultHandlers in h

Alternatives

N/A

[JounQin]

For all, I have to import it from hast-util-to-mdast not rehype-remark too. Maybe all handlers can be exported in both hast-util-to-mdast and rehype-remark? I don't know whether it is a good idea, though.

[wooorm]

This project is already mapping pre to code? I don’t understand why you have to overwrite it?

[JounQin]

@wooorm I need to find the correct language by myself.

https://github.com/rx-ts/cf2md/blob/main/src/index.ts#L64-L66

And for div, I need to remove some useless elements and covert some nodes to directives.

See also https://github.com/rx-ts/cf2md/blob/main/src/index.ts#L25

[wooorm]

In confluence's HTML, pre can be used without code inside

The same is true in normal HTML:

hast-util-to-mdast/test/fixtures/pre/index.html

Line 1 in a02be0e

<pre>alpha();</pre>

[JounQin]

The same is true in normal HTML:

The language info is on pre node:

<pre data-syntaxhighlighter-params="brush:yaml;">text</pre>

So I need to wrap it into a code node with className: "language-yaml" to reuse code handler.

[wooorm]

Right, but I don’t understand why you now have all that extra code in the pre handler, instead of import { code } from 'hast-util-to-mdast/lib/handlers/code.js, using that, and only adding data-syntaxhighlighter-params support?

(I specifically don’t understand why this part is needed: https://github.com/rx-ts/cf2md/blob/980c2f8002744aa25dba50b190d65177c26d591a/src/index.ts#L82-L101)

[JounQin]

(I specifically don’t understand why this part is needed: un-ts/cf2md@980c2f8/src/index.ts#L82-L101)

The node is still hast, I have to reuse code to convert it to mdast, or is there any better way?

[wooorm]

The node is still hast, I have to reuse code to convert it to mdast, or is there any better way?

You can import { code } from 'hast-util-to-mdast/lib/handlers/code.js and use code(...arguments)?

---

Do you want to:

• Get access to the handlers in handlers/ by their name?
• Get access to an object mapping HTML tag names to handlers? (this object:

  hast-util-to-mdast/lib/handlers/index.js

  Line 33 in a02be0e

  export const handlers = {

  ). (this sounds better to me)

---

If it was named defaultHandlers, then it shouldn’t include what you overwrite it with, right? If you define p to be something else, then defaultHandlers.p should be the original handler, not your handler?
That’s why I think I’d prefer an export from the root of this package and rehype-remark, similar to the defaultSchema from https://github.com/syntax-tree/hast-util-sanitize#api?

[JounQin]

You can import { code } from 'hast-util-to-mdast/lib/handlers/code.js and use code(...arguments)?

I'm, https://github.com/rx-ts/cf2md/blob/980c2f8002744aa25dba50b190d65177c26d591a/src/index.ts#L4

---

What I want is h.handlers and h.defaultHandlers at the same time.

const h = {
   defaultHandlers: handlers,
   handlers: Object.assign({}, handlers, options.handlers)
}

So that I can access h.defaultHandlers.pre in my own handlers.pre.

[JounQin]

That’s why I think I’d prefer an export from the root of this package and rehype-remark, similar to the defaultSchema from syntax-tree/hast-util-sanitize#api?

This seems similar to all handler, I think we can re-export all from rehype-remark.

But no defaultHandlers is needed to be exported in root level, because h is already available in custom handler.

[wooorm]

I'm, rx-ts/cf2md@980c2f8/src/index.ts#L4

I really don’t understand why all of these lines are needed, instead of const codeNode = code(node). code() already takes care of turning node, which can be a hast code or pre element, into an mdast code node?

---

What I want is h.handlers and h.defaultHandlers at the same time.

h.handlers is already exposed:

hast-util-to-mdast/lib/index.js

Lines 89 to 91 in a02be0e

	handlers: options.handlers
	? {...handlers, ...options.handlers}
	: handlers,

.

h.defaultHandlers is similar to syntax-tree/mdast-util-to-markdown#34, as you mentioned, which I don’t think is a good idea.
The fields on h, such as handlers and inTable, are the required context to compile hast to mdast. They are mutable, they change.

defaultHandlers is readonly, you specifically want lib/handlers/code.js. It’s similar to how one or all are also useful and also exports instead of fields on h.

I think we can re-export all from rehype-remark.

Fine 👍

[JounQin]

I really don’t understand why all of these lines are needed, instead of const codeNode = code(node)

I've mentioned:

So I need to wrap it into a code node with className: "language-yaml" to reuse code handler.

https://github.com/syntax-tree/hast-util-to-mdast/blob/main/lib/handlers/code.js#L39

className: 'language-yaml'(<code class="language-yaml"></code>) is required to set lang on mdast's code node.

The fields on h, such as handlers and inTable, are the required context to compile hast to mdast. They are mutable, they change.

For most use cases, should it be { ...h, handlers: {...h.handlers, div() {}} }? What use case will remove or change defaultHandlers?

And it's the user's choice to change handlers or defaultHandlers even, if they want, I don't see what's the downside to add this.

[JounQin]

Or at least we can export {defaultHandlers} from './lib/handlers.js' like defaultSchema.

[wooorm]

@ChristianMurphy or others: which if the two PRs do y'all prefer?

[ChristianMurphy]

I'd lean toward #69
The other #68 could work, but it starts to seem a bit confusing when you start considering if/when handlers are removed or customized, would those changes come though? The other is clearer that it will get the original version.