You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 30, 2018. It is now read-only.
Currently the request method will dynamically load the default provider, depending on if you are running in node or the browser. This adds some complexity to the code and probably isn’t even needed.
We’re looking for a usage like this,
importrequestfrom'dojo-core/request';// import node support manually if we want to use itimportnodeProviderfrom'dojo-core/request/node';// set the default provider some howrequest.setDefaultProvider(nodeProvider);// the next request will go to noderequest.get(...);
Remove the dynamic loading from ProviderRegistry and just assume that defaultValue is already a provider, not a string.
Add a method to set the default provider, so it can be injected.
Create a convenience method to inject request/node as the default provider for people running in Node.
You can see a rough implementation (as well as some unrelated changes...) here,
Just my 2 cents : I like the dynamic loading.
It is consistent with all modules which you can use either in the browser or node.js ...
e.g. /text, /util, /queue, /on have switches for node/browser and as a user
I would expect to use any module without external requirements.
@sebilasse We would still support dynamic loading (even when in most environments it is definitely more desirable to make concrete at build time), it just wouldn't happen in the core of request itself. Currently the code to dynamically require down the browser path is super ugly - we queue requests while loading the provider, this kind of thing doesn't seem like it should be a request concern.
Following on: In the past, the above complications would've been removed by dealing with this in the dependency block in AMD using the has plugin to conditionally require the environment specific module. But given we're consciously trying to keep as format neutral for the future we're better placed on making these kind of module loading decisions outside of request. The point being that the environment will/should be known prior to a request being made.
Currently the
request
method will dynamically load the default provider, depending on if you are running in node or the browser. This adds some complexity to the code and probably isn’t even needed.We’re looking for a usage like this,
ProviderRegistry
and just assume thatdefaultValue
is already a provider, not a string.request/node
as the default provider for people running in Node.You can see a rough implementation (as well as some unrelated changes...) here,
master...rorticus:no-streams
The text was updated successfully, but these errors were encountered: