Closed rorticus closed 7 years ago
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.
Fixed in #261
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,
https://github.com/dojo/core/compare/master...rorticus:no-streams