Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable "document" from which to create DOM elements #69

Open
ultraq opened this issue Apr 30, 2017 · 0 comments
Open

Configurable "document" from which to create DOM elements #69

ultraq opened this issue Apr 30, 2017 · 0 comments

Comments

@ultraq
Copy link

ultraq commented Apr 30, 2017

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?

why not both

(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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant