require.ready is no longer supported

[thecheatah]

requirejs no longer implements require.ready method, instead asks to use domReady. Please use this in the dojo.ready module.

[bill]

@thecheatah - As I mentioned on the mailing list, this should be filed against the Loader component. Switching the component.

@rcgill - the code in question is apparently:

	// define requireCompleteSignal; impl depends on loader
	if(has("dojo-loader")){
		require.on("idle", onLoad);
		requestCompleteSignal = function(){
			if(require.idle()){
				onLoad();
			} // else do nothing, onLoad will be called with the next idle signal
		};
	}else{
		// RequireJS or similar
		requestCompleteSignal = function(){
			// the next function call will fail if you don't have a loader with require.ready
			// in that case, either fix your loader, use dojo's loader, or don't call dojo.ready;
			require.ready(onLoad);
		};
	}

[Rawld Gill]

In [27540]:

removed requirejs compat for require.ready since requirejs doesn't support that API anymore; fixes #14587

[Richard Backhouse]

With the removal of the "if" block the code will always call require.on and require.idle. As these are not AMD spec'd how are other AMD loaders supposed to support this module ?

[Adam Peller]

reopening in consideration of feedback from @rbackhouse. Are on() and idle() likely to be common API? If not, can they be replaced also?

[Rawld Gill]

The dojo/ready module executes callbacks under two conditions:

1. DOM content loaded is achieved.
2. All requested modules have arrived and been evaluated.

It is possible to add callbacks for only the DOM content loaded condition with the dojo/domReady plugin, and this plugin uses no special dojo loader functions. Other loaders have implemented this functionality.

The two condition variant is exclusive to dojo. It was originally called dojo.addOnLoad and renamed to dojo.ready. Other loaders do not implement this function and it takes special loader knowledge to know when all requested module have arrived. There has been debate about defining a public interface to determine this kind of loader state. But, to date, there is no agreement to go forward.

In short, if you want to use dojo.ready() or the dojo/ready plugin, then you must use the dojo loader.

[Richard Backhouse]

In short, if you want to use dojo.ready() or the dojo/ready plugin, then you must use the dojo loader.

The dojo/ready reference is originating from dojo/dijit code. That means that dojo is unusable with other loaders.

[Richard Backhouse]

The reference is in dijit/_WidgetBase.

[bill]

Well, that reference in dijit is only used when the async flag is set to false, or more specifically, when "dijit-legacy-requires" is true. There might be other cases though when dojo/ready does get used.

But anyway, dojo/ready will go away for 2.0 so this is not a long term issue.

[Richard Backhouse]

While the call to ready is conditional the fact that the dojo/ready module is listed as a depedency in the define call ensures it get loaded regardless. It's when dojo/ready is loaded that the proprietary API calls are made.

[bill]

Ah I see. OK, and that's due to [26754]. Could workaround it by something like below, but it's probably not worth it at this point.

if(has("dijit-legacy-requires")){
	require(["dojo/ready", function(ready){
 		ready(0, function(){
			var requires = ["dijit/_base"];
			require(requires);	// use indirection so modules not rolled into a build
		});
	});
}

[Adam Peller]

Perhaps it's worth an experiment or branch to see how close this gets us to requirejs compatibility. *If* this is all that's preventing requirejs compatibility, waiting until 2.0 could be a problem for users stuck on the 1.x line. Should we open a new ticket to consider this?

[bill]

You can experiment if you like. I don't think that's the only issue though.

Dojo's hash.js, hccss.js, parser.js, touch.js, and uacss.js, and dijit's Focus.js, hccss.js, _CssStateMixin.js, RichText.js, and Viewport.css all use dojo/ready rather than dojo/domReady! because dojo/domReady! has issues when the app is running in sync mode (even though those modules are written in AMD). Plus dojo/ready is used by robot to tell when the document in the iframe has finished loading.

The other reason those modules use dojo/ready is for the priority queue, i.e. to make sure that hccss etc. runs before the parser does.

[afinnell]

Replying to bill:

Well, that reference in dijit is only used when the async flag is set to false, or more specifically, when "dijit-legacy-requires" is true. There might be other cases though when dojo/ready does get used.

But anyway, dojo/ready will go away for 2.0 so this is not a long term issue.

Four years later...

Unfortunately using the philosophy that everything will be better in 2.x means that everyone suffers in the meantime. It's been four years since this post and we still don't have a working 2.0 version with the alleged fix. Why can't this be fixed? It seems incredibly easy. I'll even submit the code if needed.

[dylan]

@afinnell: Hindsight is definitely 20:20. If we could go back in time, we'd probably have made Dojo 2 just be a cleaned-up, AMD-only version of Dojo 1.x, and the great work we're doing now for Dojo 2 ( ​http://github.com/dojo/meta ) would be Dojo 3. On the plus side, we're closing in on Dojo 2 beta in the next few months. For what it's worth, Dojo has been reasonably compatible with RequireJS since Dojo 1.9 a few years ago.

If you want to submit a PR, I'll review and land it. We're planning a 1.12 release in November.