Fix for matches resolving document.body at require time.

[vdh]

A fix for issue #29

Delayed the resolution of document.body inside matches to the first call, instead of at require time. Before DOMContentLoaded has fired, matches will return null.

[robinknox]

Hi @jquense any chance you could review this? I get the same error about matches being null on my Cordova Meteor build which uses react bootstrap.

[jquense]

i've noted my thoughts on this category of changes in other places. Something that changes a single method to use a lazily evaluated document.body doesn't fix the problem, it just moves it for one method. Any fix to this will need to be holistic to the all of the dom-helpers package

[vdh]

@jquense I did have a look over all the other utils in dom-helpers, and as far as I could tell, matches is the only one that attempts to reference document.body immediately at require-time, and AFAIK that's the only thing that isn't available until after DOMContentLoaded.

I avoided making any further changes to any of the other utils, both because I couldn't diagnose any other potential problems to justify more changes, and also because I didn't want to get on your bad side by making any unnecessary refactoring beyond the essential changes to fix #29

I've been using Webpack's NormalModuleReplacementPlugin to successfully patch matches with this fix, and nothing else in dom-helpers appears to break due to loading in the head.

If there's any details about other problems I'm missing here, please let me know, because I really want to help out fix this issue.

[jquense]

Huh, maybe there isn't anything else left... I'll take look and circle back

[robinknox]

Hi @jquense just wondering if you've had time to take a look for any other changes needing done before this can go in?

[jquense]

ya'll are right this is the only instance, sorry for the noise there. thanks!