Usage in web worker

[jlarmstrongiv]

Expected Behavior

Render html to react elements

Actual Behavior

Uncaught (in promise) Error: This browser does not support `document.implementation.createHTMLDocument`
    at parseFromDocument (html-react-parser.js?v=474f97b5:38:13)
    at domparser (html-react-parser.js?v=474f97b5:109:25)
    at HTMLDOMParser (html-react-parser.js?v=474f97b5:277:65)
    at HTMLReactParser2 (html-react-parser.js?v=474f97b5:1778:72)

Steps to Reproduce

Try using html-react-parser in a web worker

Reproducible Demo

I will create a demo if there is interest in fixing this bug.

I believe it’s due to the more limited environment of web workers, which does not have access to window or document objects.

A similar issue for Vercel Edge Functions was closed as wontfix #736

Regardless, I’m open and looking for workarounds to make html-react-parser work in a web worker

Environment

• Version: 5.1.10
• Platform: Web Worker
• Browser: Chrome
• OS: MacOS

Keywords

Web worker

[remarkablemark]

@jlarmstrongiv could this help? remarkablemark/html-dom-parser#502

[jlarmstrongiv]

After an hour of debugging—I confirmed the answer is overriding the version to the server version. @remarkablemark adding 'html-dom-parser/server' would be extremely helpful for these use-cases

[remarkablemark]

@jlarmstrongiv would you be interested in improving the README.md?

Since this feels more like an edge case, I think it makes more sense to make custom overrides in the bundler config.

[jlarmstrongiv]

Since this feels more like an edge case, I think it makes more sense to make custom overrides in the bundler config.

Rendering in WinterCG runtimes (Vercel, Cloudflare, and other functions) and web workers are becoming more and more common these days.

I personally prefer adding the export because that will be the same no matter what. Overriding bundlers is often error prone, painful, and bundler-specific, particularly when throwing in esm. Sometimes it may not even be possible. For example, it’s not possible to override just the web worker—it’s all or nothing. Whereas, with imports, I have a lot more flexibility.

If you’re up for adding that export, I’ll gladly update the README.md

[remarkablemark]

Could you clarify what you mean by adding an export? Do you mean this:

import 'html-dom-parser/server';

[jlarmstrongiv]

Yes, like import parse from 'html-dom-parser/server'. Though, remarkablemark/html-dom-parser#502 brings up a very good point that the server export would need to be propagated to html-react-parser too

[remarkablemark]

Gotcha that might be a bit tricky to propagate since html-dom-parser relies on the bundler to figure out if the library uses the server parser or the browser parser.

[jakeonfire]

we are running into this issue with react-rails pre-rendering, which uses ExecJS/MiniRacer/Node.js to render on the server. but we also render the same components in the browser. for now we're using a polyfill to stub out the document API to mvp (read: no errors, but no dom either) in the prerendering case, which isn't ideal.

[josh-sanger]

Getting this issue as well with a CloudFlare worker environment and Vite. Would love a fix here.

Adding html-react-parser to the vite config like below removes the error export is not defined however I also encounter the poster's error message

ssr: {
    optimizeDeps: {
      include: [
        'html-react-parser',
      ],
    },
  },

[dustin-rcg]

In my case, I want to render a PDF report using @react-pdf/renderer in the browser. Part of the report contains rich text, which we are using html-react-parser to transform into React DOM, and then into the React PDF object model. It makes sense to do this, since the reports are a subset of what we show in React, so that transformation always needs to be done anyway. However, now for long reports that are freezing the browser we want to move them to web workers, and we are finding we can't use this package inside web workers in those cases.