remarkablemark / html-react-parser

📝 HTML to React parser.
https://b.remarkabl.org/html-react-parser
MIT License
2.15k stars 129 forks source link

Usage in web worker #1403

Open jlarmstrongiv opened 7 months ago

jlarmstrongiv commented 7 months ago

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 https://github.com/remarkablemark/html-react-parser/issues/736

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

Environment

Keywords

Web worker

remarkablemark commented 7 months ago

@jlarmstrongiv could this help? https://github.com/remarkablemark/html-dom-parser/issues/502

jlarmstrongiv commented 7 months ago

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 commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

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

import 'html-dom-parser/server';
jlarmstrongiv commented 7 months ago

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

remarkablemark commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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',
      ],
    },
  },