semantic-dom-diff

[Hypercubed]

Hello All,

I'd like to build a more extensible version of https://www.npmjs.com/package/@open-wc/semantic-dom-diff . Using rehype seams like the right path. I've written a few unified/rehype plugins to do the normalization but the last step is stringifying back to HTML. To get clean dom-diffing I need tags and attributes to be printed on individual lines like so:

<div
  class="..."
  style="...">
  Content
</div>

This is not currently how rehype-stringify/hast-util-to-html works and there are no options I can find that can force that. So, my question: should I create a fork of hast-util-to-html to get the output I need or do you think there are some resonable options that could be added to rehype-stringify/hast-util-to-html?

TY

[ChristianMurphy]

There was some experimental work on diffing done here: https://github.com/syntax-tree/unist-diff
Still in an early phase, but something you may be able to continue/build on if your interested in going a more generalized AST route.

To get clean dom-diffing I need tags and attributes to be printed on individual lines
question: should I create a fork of hast-util-to-html to get the output I need or do you think there are some resonable options that could be added to rehype-stringify/hast-util-to-html?

I'd defer to @wooorm, I believe https://github.com/syntax-tree/hast-util-to-html/blob/46dbdd85314942221d843e24190b5a78466a0753/lib/element.js#L123-L135 would be the segment of code that would need to change.
Again similar to the comment above, normalizing content may produce a usable result, but I suspect using an AST, which smooths over many syntactic differences could produce an even better result.

[Hypercubed]

@ChristianMurphy Thank you for the link! Yes, that is a path to explore. In my use case (testing) it's more important to know where the difference is rather than what. Using vdom-diffing would require a complicated step to convert back to a readable format.

[wooorm]

Thanks for your patience Jayson!

A proper version of this would know about how many attributes there are, how big the indent is, and then “pretty print” based on that.
In your case however, such fancy formatting isn’t needed. But I do feel like actually adding a feature like this to hast-util-to-html should be smarter than: just format every attribute on their own line. And your expected output also needs to know about indent 🤔

Some more ideas: there are some packages in rehype-minify why might be useful here: e.g., attribute ordering. Maybe a good enough version is to rehype-minify and then rehype-format? It wouldn’t print attributes on their own lines though, but diff algorithms typically can already deal with partial line changes?

Is that fine enough, or do you still need (indented) attributes on their own lines?

[Hypercubed]

Yes, basically that... I'm using rehype-minify-whitespace and a few custom plugins to normalize the HTML. So far so good except for the final rehype-stringify / hast-util-to-html output. I'm using a line-by-line differ so having the attributes on their own lines would really help. I can look into a better diff algorithms but don't know of any that wouldn't decrease readability.

BTW, this is the project: https://github.com/swimlane/cy-dom-diff .

[wooorm]

As hast-util-to-html formats the HTML pretty strictly, e.g., quotes are guaranteed to be " and available, could you do a regex replace afterwards? Other idea: prettyhtml-hast-to-html is a fork that does support line wrapping and I think it (sometimes) prints attributes on their own lines

[Hypercubed]

Thanks for the discussion. Sounds like the best option would be for a fork of rehype-stringify / hast-util-to-html rather than additional options.