Unnecessary custom plugin dojo/request/default!

[Randy Hudson]

Our AMD support processes all plugins on the server and not in the browser. I don't know if anything actually uses dojo/request, but when we scan it we come across a plugin we don't know how to handle: dojo/request/default!.

Looking at default.js, it seems unnecessary. Instead, dojo/request should require: "./has!host-browser?./request/xhr:./request/node" or something similar.

[Bryan Forbes]

dojo/request/default! is absolutely necessary for the interface to dojo/request to work correctly. The has switch you have put here would work, except that there is also a way to set the platform default through a configuration option. This means that any provider can be used as the default provider for an application. The most useful provider used in this configuration would be dojo/request/registry which allows providers to be registered for URLs or other criteria and then routing all requests through the dojo/request/registry function call. The end result is that library code can use dojo/request and be provider agnostic (much like how stores work). Since dojo/request is a new API as of 1.8, no library code currently uses it because of backwards compatibility, however moving forward any new library code that makes requests should use dojo/request.

[Randy Hudson]

Bryan, your comment just seems to highlight yes another solution to a problem that is already solved in AMD. If a client needs to customize the default implementation, this should be done via the common config:

{
    map: {
        '*': {
            'dojo/request': 'dojo/request/registry'
        }…
}

This way, when any module asks for "dojo/request", it would receive the dojo/request/registry module's implementation.

[Randy Hudson]

Would you please consider reopening this, or, if the config map approach isn't sufficient, explain why.

[ben hockey]

the map approach is interesting but one important point to note is that when the API for dojo/request ​was added, the map config was ​not part of AMD but ​plugins were. so the problem was solved with AMD... using plugins.

[Randy Hudson]

If dojo really intends to embrace AMD, then it seems like adopting the AMD solution would make sense here. Given how new dojo/request is, very few would have started using it and even fewer would have started replacing its implementation using "config-requestProvider".

What about deprecating the config-requestProvider property? dojo/request would then only reference the default! plugin if that property were in use, so its dependency would look something like:

"./has!config-requestProvider?./request/default!:host-browser?./request/xhr:./request/node"