I thought it would be worth mentioning this point for Webpack 2 consideration. The loader spec strictly specifies System.loader.import as the dynamic import entry point, instead of System.import as it used to be.
The other problem with using System.import is that strictly System.import shouldn't have any parent knowledge without a second argument. That is you'd really want System.import('x', parentName) to be the contextual require. Assuming System.import is already parent-scoped is going to not be true on the upgrade path at all. In SystemJS, we've defined a locally scoped __moduleName variable to allow for the above, but again it ends up being a custom solution.
In reality modules will have a contextual import function syntax available that will automatically scope the import to the current module parent so that this won't usually be necessary making for a nicer patter in ES modules. Perhaps it could be worth enquiring about that status of that syntax as well.
There might be the scope for a little more freedom to experiment here too. For example trying out one spec suggestion syntax like:
export function dynamicLoad() {
return import.default('x') // default export (import.namespace being the normal namespace import)
}
which was discussed in whatwg/loader#36 (comment). If the spec does implement it, the upgrade path works. If the spec doesn't implement it, then it's just a breaking change to adjust, so it's a no different scenario than using System.import.
One could even then experiment with another possible syntax like:
export function async dynamicLoad() {
return await import 'x';
}
And treating that import 'x' as the dynamic import. Would (import 'x').then(...) make sense with that grammar?
At some level it does come down to betting on something somewhat custom, and aiming to minimise the risk and inform users about the situation.
The approach SystemJS is taking here is not trying to polyfill System.loader due to potential conflicts when native implementations eventually land. Instead the idea is to stick with the "old" API of System.import and then double this up with a smooth upgrade path to a best practice non-conflict SystemJS.import, only switching into System.loader.import when we're sure there won't be a native conflict.
At least that's the best approach I've been able to come up with so far. If you've already considered this not to worry, but just to check the System.import decision should at least be made knowingly to avoid an upgrade path issue like SystemJS now has (although it would be great for SystemJS to be able to share the same convention actually, so I probably should have just shut up here!).
leonyu, MarkPieszak, jolyndenning, jhnns, Jessidhia and 5 more
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4