search

syntax-tree / hast-util-to-dom

utility to transform hast to a DOM tree
https://unifiedjs.com
ISC License
19 stars 8 forks source link

Support JSDOM #3

Closed tripodsan closed 5 years ago

tripodsan commented 5 years ago

Subject of the feature

When running in nodejs, the global document is not available. There is no way to pass in the JSDOM document or document implementation.

Problem

Without this feature, this util is useless in nodejs.

Expected behaviour

It should be possible to pass in the document via options eg:

toDOM(root, { document: new JSDOM().window.document });

Alternatives

non so far detected.

wooorm commented 5 years ago

Good idea! Can you work on a PR?

tripodsan commented 5 years ago

Can you work on a PR?

sure.

wooorm commented 5 years ago

Great! I do wonder if using hast/rehype with jsdom kinda defeats the purpose a bit. They’re kind of alternatives to each other, and both JSDOM and rehype-parse work through parse5. But this utility is much smaller if there’s access to browser APIs.

tripodsan commented 5 years ago

we're using it together with remark, that turns markdown into mdast. which can be turned into hast. I want to use jsdom in the end, and currently there is no good mdast-to-dom util yet, as far as I know.

wooorm commented 5 years ago

You’re right that this is the way to go, and it’s not duplicate work if you’re not using rehype-parse. But I’m wondering why you’d want JSDOM in the end?

wooorm commented 5 years ago

I made a PR!

trieloff commented 5 years ago

But I’m wondering why you’d want JSDOM in the end?

(@tripodsan and I are working on the same project) our target audience are web developers who are very familiar with the DOM APIs so that the congruence of working in MDAST vs HAST is not as valuable as giving them a familiar tool to tweak the HTML output of the process.

wooorm commented 5 years ago

Thanks for the info! That makes more sense!

I believe you could also go hast -> string, string -> jsdom, I don’t think there are disadvantages of that.

In the future we could also for example set position on DOM nodes, in this library, that would be a cool advantage: a lint rule that checks the DOM and warns about something going on at a specific place in a markdown file!

trieloff commented 5 years ago

We will probably need position at some point in the DOM, as we will build an editor that should synchronize scroll position, cursor position (and if possible, select ranges)

tripodsan commented 5 years ago

I believe you could also go hast -> string, string -> jsdom,

yes. that's what we did before. but it was too slow :-)

We might also need support for type: 'raw' soon. those nodes are generated by remark, when you have inline HTML in the markdown. I will provide a new issue and PR eventually :-)