Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#16469 closed defect (wontfix)

Unnecessary custom plugin dojo/request/default!

Reported by: Randy Hudson Owned by:
Priority: undecided Milestone: tbd
Component: Core Version: 1.8.1
Keywords: Cc: cjolif
Blocked By: Blocking:

Description

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.

Change History (6)

comment:1 Changed 7 years ago by Bryan Forbes

Resolution: wontfix
Status: newclosed

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.

comment:2 Changed 7 years ago by 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.

comment:3 Changed 7 years ago by Randy Hudson

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

comment:4 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by 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"

comment:6 Changed 7 years ago by cjolif

Cc: cjolif added
Note: See TracTickets for help on using tickets.