Async consistency

[cowsrule]

Minor code-review point after seeing a link to you lib.

It's (almost) always a good idea to guarantee that your callback will be either consistently async or consistently sync in every case it is used. Not having this guarantee can cause hard to find and hard to reproduce bugs in your code.

In the case that the DOMContentLoaded event is missed, the callback will be sync. In the case that the event has not yet been fired, the callback will be async. Consider wrapping the explicit call to the callback in a setTimeout to guarantee that the invocation of the callback will always be async.

[lukechilds]

I was aware that's best practise, however I assumed that a Promise executer ran async so everything inside was also async. Turn out that's not correct.

Fixed: 1284c58

Thanks for the feedback 👍

[Yvem]

Disagree.

The callback (node style) should indeed be always async, but not the promise resolution, which is expected to be potentially synchronous by the promise spec, doesn't have too.

[lukechilds]

@Yvem Good point. Fixed in v1.2.5.

[Yvem]

When reading the code, it seems that the return value from the callback has an effect on the resolved value of the promise. Is it by design ?

[lukechilds]

That's an undocumented side effect.

With the new change in v1.2.5 the timeoutID for the callback will be the resolved value of the promise. I don't really expect people to be mixing callbacks and promises though.

[lukechilds]

@Yvem This was annoying me, just fixed the weird resolve value behaviour: #11