I've got a project that uses JSDOM for some server-side DOM processing, and tests that emulated that environment by me adding JSDOM globals to Node's global scope and then using hyperscript to whip up some mock DOM trees. However, I recently came across some advice from the JSDOM authors (also repeated on several issues on their GitHub and some related projects) that strongly advise against this. So, in hopes of cleaning up my programmer sins, I went about removing JSDOM globals from my test environment.
This led to a problem in that now my test environment is using DOM elements created by hyperscript's html-element shim/dependency because the window object is no longer globally available. Basically, this assumption in hyperscript is kicking in (https://github.com/hyperhype/hyperscript/blob/master/index.js#L4) and I'm left with elements/nodes with rather incomplete DOM APIs, leading to falsely failing tests.
If I could pass a custom window object to hyperscript, like the one created by JSDOM, then I could get around this. I was almost on my way to PR such a thing too, but it got me thinking that it would lead to an API change. Like, I'd be destroying the super-simple API and making it this:
const h = require('hyperscript')(/* custom window object here or nothing and fall back to html-element as usual */);
Would you be open to such an API change? Or, can you think of a way to retain the super-simple API and have the configurability?
(After writing all this I also noticed this context() thing, but the window is set up outside of that too. Maybe something that changes that method signature would retain the API? It's late here, I can't think any better.)
I've got a project that uses JSDOM for some server-side DOM processing, and tests that emulated that environment by me adding JSDOM globals to Node's global scope and then using hyperscript to whip up some mock DOM trees. However, I recently came across some advice from the JSDOM authors (also repeated on several issues on their GitHub and some related projects) that strongly advise against this. So, in hopes of cleaning up my programmer sins, I went about removing JSDOM globals from my test environment.
This led to a problem in that now my test environment is using DOM elements created by hyperscript's html-element shim/dependency because the window object is no longer globally available. Basically, this assumption in hyperscript is kicking in (https://github.com/hyperhype/hyperscript/blob/master/index.js#L4) and I'm left with elements/nodes with rather incomplete DOM APIs, leading to falsely failing tests.
If I could pass a custom
windowobject to hyperscript, like the one created by JSDOM, then I could get around this. I was almost on my way to PR such a thing too, but it got me thinking that it would lead to an API change. Like, I'd be destroying the super-simple API and making it this:Would you be open to such an API change? Or, can you think of a way to retain the super-simple API and have the configurability?
(After writing all this I also noticed this
context()thing, but thewindowis set up outside of that too. Maybe something that changes that method signature would retain the API? It's late here, I can't think any better.)