Giter Club home page Giter Club logo

when-dom-ready's Introduction

when-dom-ready

$(document).ready() for the 21st century

Build Status Coverage Status npm GitHub Donate Bitcoin Donate Lightning Donate

Returns a Promise for cleaner usage, provides a Promise chain helper function and can also be used as a pure function. The Promise will resolve instantly if the DOM is already ready.

Browser Compatibility

  • IE9+ (requires Promise polyfill)
  • Edge *
  • Firefox 29+
  • Safari 8+
  • Chrome 33+
  • Opera 23+

Install

npm install --save when-dom-ready

or for quick testing:

<script src="https://unpkg.com/when-dom-ready"></script>

Usage

import whenDomReady from 'when-dom-ready';

whenDomReady().then(() => console.log('DOM is ready yo!'));

You can still use callbacks if you want to:

whenDomReady(() => console.log('DOM is ready yo!'));

Promise chain helper

There is also a little helper function, whenDomReady.resume(), that pauses the execution of a Promise chain and then resumes it with the last value once the DOM is ready.

This allows you to specify complex async control flow in simple readable code:

fetch('/my-badass-api.json')
  .then(getSomeProcessingDoneWhileWaitingForDom)
  .then(whenDomReady.resume())
  .then(injectDataIntoDom);

Pure usage

You can make the function pure by passing in a document object. This is really useful for tests and mocking environments.

For example this works in Node.js:

const Window = require('window');
const whenDomReady = require('when-dom-ready');

const { document } = new Window();

whenDomReady(document).then(() => console.log('DOM is ready yo!'));

Again, you can use the callback version as a pure function too:

whenDomReady(() => console.log('DOM is ready yo!'), document);

And of course the helper:

//...
  .then(whenDomReady.resume(document))

License

MIT Β© Luke Childs

when-dom-ready's People

Contributors

greenkeeper[bot] avatar lukechilds avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

when-dom-ready's Issues

An in-range update of coveralls is breaking the build 🚨

The devDependency coveralls was updated from 3.0.5 to 3.0.6.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

coveralls is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

Commits

The new version differs by 3 commits.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Export as an UMD module / or is the build broken ?

This is a browser lib. However, it's written in CommonJS (aka. node modules), cf. src "module.exports = ..."

The file exposed in "dist" is still in CommonJS.

Thus this lib cant be used "as is" in a browser, it must be passed in a transpilation/bundling stack like browserify.

You should export an UMD module, which would work in any environment.

An in-range update of coveralls is breaking the build 🚨

Version 2.13.2 of coveralls just got published.

Branch Build failing 🚨
Dependency coveralls
Current Version 2.13.1
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As coveralls is β€œonly” a devDependency of this project it might not break production or downstream projects, but β€œonly” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this πŸ’ͺ

Status Details
  • ❌ dependency-ci An error occured Details
  • βœ… continuous-integration/travis-ci/push The Travis CI build passed Details
  • βœ… coverage/coveralls First build on greenkeeper/coveralls-2.13.2 at 100.0% Details

Commits

The new version differs by 3 commits.

  • 5ebe57f bump version
  • 428780c Expand allowed dependency versions to all API compatible versions (#172)
  • eb1b723 Update Mocha link (#169)

See the full diff

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Const declarations are not supported in strict mode.

I get this error when run on iOS9 iPad.
Do you have an idea why babel didn't transpile your "const" to var?

my loaders cfg (webpack 1.x)

loaders : [
	{
		test: /\.js?$/,
		exclude: /node_modules(?!(\/|\\)when-dom-ready)/,
		loaders: [ 'babel' ],
	},
],

Should you consider distributing a pre-built version?

I may be using this wrong, but I've been having trouble with this package recently since using import whenDOMReady from 'when-dom-ready' includes the file from /src. Given this is a non-compiled file using arrow functions, I am having to run it through webpack and babel-ify it myself. I don't ever have to do this with other libraries, making me feel like it's a common convention to pre-build the library for distribution, although I really might be wrong. I don't know a ton about common conventions for distributing npm modules.

Should the module be running a build step that it is missing, or am I missing something? (Thanks, trying to learn and contribute; not trying to criticize).

Async consistency

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.

Loading document readyState

Where you have:

const loadedStates = ['interactive', 'complete'];
if (loadedStates.includes(doc.readyState)) {
}

https://github.com/lukechilds/when-dom-ready/blob/mater/src/index.js#L22

Considering there are only 3 document ready states (loading/interactive/complete):

https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState

Would it be better to do:

if (doc.readyState !== 'loading') {
}

Would be one less constant (the array of 2 stings), and a slightly faster string comparison (instead of checking if the array includes).

:-)


Just for comparison, I've been using the following in my JavaScript for a number of years, and I've not had any problems so far:

if (document.readyState !== 'loading') {
    window.setTimeout(init); // Handle asynchronously
} else {
    document.addEventListener('DOMContentLoaded', init);
}

Enhance confidence by listing supported case

correctly detecting dom ready is not trivial.

I'm not confident (no offense) with your nice lib unless it lists in the README the most common pain points:

  • browser compatibility ?
  • what if loaded and called after dom ready happened ? Will it trigger ?
  • exact concept of dom ready ?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.