Question: How Isomorphic Works about isomorphic-dompurify HOT 4 CLOSED

First, let's ignore r(m) function because its purpose is more or less clear and it doesn't add any significant complexity.

I can't give you 100% answers but can share my considerations...

1. In the Node environment, this piece of code module.exports = global.DOMPurify = [some code] allows us both:

const DOMPurify = require('isomorphic-dompurify');
DOMPurify.sanitize('<iframe>Iframe!</iframe>');

and

require('isomorphic-dompurify');
DOMPurify.sanitize('<iframe>Iframe!</iframe>');

2. My guess is that module.exports = global.DOMPurify = global.DOMPurify || [init logic] was aimed as a caching mechanism (sort of a singleton), so that if you would import the module twice, it would execute the init logic only once:

require('isomorphic-dompurify');
require('isomorphic-dompurify');

but modern versions of Node cache multiple imports of the same module anyway, so it can be redundant.

3. I was thinking about why we have both conditions for checking whether it's Node: global.DOMPurify and typeof process === 'undefined'. But then I confirmed that <script type="module" doesn't have global object defined, so the global object only exists inside a Node script.

4. I still need to check what Webpack produces when configured to compile to es5.

The Isomorphic Unfetch was created quite a while ago and it could be targeted to previous versions of Node and browsers. I guess they tried to predict all possible use cases, such as Webpack, SSR, without SSR, different browsers, different browser versions. And as I already mentioned, I just reused the approach that worked fine for me on other projects.

It's great that there are people who question solutions - that's a rare skill. But if we have some risk to break what's already working well, it'd be great to have it tested in all possible environments. But who can guarantee we tested it everywhere?

from isomorphic-dompurify.

@kkomelin Thanks for diving in!

Is it fair to say that my summary was accurate then? The biggest piece I was missing was some of the context around isomorphic-fetch and the support for older versions of node / browsers?

I don't think we need to change the code - as you noted, this works and a re-write will likely introduce bugs that the isomorphic-fetch folks already experienced and squashed.

I just like understanding how things work (and, not a formally trained computer scientist, some terms like isomorphic can be confusing to me 😄 ).

Cheers!

from isomorphic-dompurify.

@stephencweiss Thanks for your kind words and the question.

Let's start from not using "virtual DOM" term in this context because it can be confused with the virtual DOM which is used in React and other modern frontend frameworks. As I understand, JSDOM has a different purpose and implementation.

To be honest, I didn't change much in the skeleton code which is provided by the Isomorphic Unfetch because it worked for me well enough and I didn't find anything suspicious in it at the time of releasing Isomorphic DOMPurify.

But I'm open to improve the code, so please give me some time to check my assumptions and provide a more detailed answer.

from isomorphic-dompurify.

@stephencweiss Yes, I think your summary of the module logic was quite accurate. Thanks again for asking this question. Good one.
It seems like we can close the issue for now but feel free to create new ones when necessary.

from isomorphic-dompurify.