Require-inline support #35

wants to merge 1 commit into


None yet

2 participants


This is a hopeful pull request. My expectation is to be shot down briskly. But since this is the core of my workflow right now I need to give it a go.

Basically, I'm using require-inline to sync download progressive enhancement dependencies that are critical for the current point in the page load. I think this is a fundamental issue and this solves it in RequireJS quite neatly, with no risk. In-page code being a separate use case to post-page-load code, which should always be async.

If I write a module with require-cs, I immediately lose this benefit due to the AJAX call. But if it just checks one flag to provide sync AJAX that will solve this entirely.

The flag is created during a sync cycle and removed in the same cycle, so there is no chance of leakage into other requires.

Happy to discuss further, and thanks for taking the time to consider as always.

jrburke commented Nov 14, 2012

Yes, this is a bit too specific. However, if you want to rework it to something more general, where the cs module will read a module config that allows an alternate call, I would be more open to that. So, something like how the text plugin has custom XHR hooks.

As part of the change it would be good to have the README updated with info on the config setting too.

@jrburke jrburke closed this Nov 14, 2012

That sounds great - I'll do this in the next couple of weeks then.

@guybedford guybedford referenced this pull request in requirejs/requirejs Nov 17, 2012

Ensure empty config is a live reference #532


Since jrburke/requirejs/532 is still a bit uncertain, I thought I'd suggest an alternative here as well.

Another way of having global control over xhr would be to make the xhr hooks global hooks as well.

The simplest is something along the lines of requirejs.createXhr and requirejs.onXhr.

It could also even be worth creating a minimal xhr implementation based on a simple interface:

  requirejs.xhr = function(method, url, data, callback, errback);

Such an interface could support overriding with more functionality. For example to implement headers one could override the implementation:

  requirejs.xhr = function(method, url, data, callback, errback);
  requirejs.xhr.setHeaders = function(headers); //adding to a buffer until the next xhr call

This would save a lot of rewriting between plugins, while not trying to provide an implementation that is too heavy but still flexible for changes.

I'm more than happy to dive in and help in either of the above directions.

jrburke commented Nov 21, 2012

xhr creation is outside the scope of core module definition and loading, so I do not want to tie xhr creation to the global object. It also breaks the locality of modules -- there cannot be scoped "createXhr" for a set of modules. It is better for modules to all have a common xhr dependency. While I am not likely to do that for the requirejs/text version of a "text" plugin, other people can provide a module that would satisfy the "text" dependency use cases that does depend on an xhr module.


This is the module I use for this purpose - It supports http requests in both node and the browser with the same api dependency.

I suppose the way forward here is to stick with the local createXhr hook, which will be the same for require-cs and text.

Then I will just ensure that an empty config object is specified in the initial config so that it can be updated during runtime. The config fix of jrburke/requirejs/532 would be useful for avoiding the need to enter an empty config object here, but not critical. So I will continue to work on the integration in this form. If you have any other suggestions please let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment