2 questions about ES6 module loaders

[Glen]

> What's the reason for this?
With something like PJAX, you would look for a header in order to 
disable the layout. I thought maybe if you loaded a JS module and it 
imported a "view", that view could share the same endpoint as the one 
used to render the whole page. It's not a big deal though, I was just 
curious.

Thanks for your help.

PS. "from X import Y" syntax would have been useful in cases where IDEs 
provide auto-completion. I know it's too late for changes now.

On 2015/05/30 21:10, Tab Atkins Jr. wrote:
> On Sat, May 30, 2015 at 6:57 AM, Glen <glen.84 at gmail.com> wrote:
>> I apologize if these are silly questions, but:
>>
>> 1. Do ES6 module loaders make use of the browser cache? f.e. If you request
>> a JS module and that JS file is in memory/on disk, will it return that file
>> instead?
> *All* network requests use the browser cache.  Assuming you've set the
> correct caching headers, you'll get a cached version when you make a
> request a second time.  Only the user can work around this, by
> clearing their cache or doing a hard refresh.
>
>> 2. Will ES6 module loaders set a header that indicates that the request is
>> not a regular browser request? (similar to how JS libs set an
>> X-Requested-With header) If not, will it be possible to add custom headers
>> to such requests?
> What's the reason for this?
>
> If you implement a custom loader, you can add whatever headers you
> want (subject to Fetch restrictions).
>
>> I don't really know which method browsers will use to load modules – I
>> assume XMLHttpRequest is used for current polyfills, but I don't know what
>> the actual implementations will use (?).
> Native loader will use the browser's normal request mechanisms.
>
> ~TJ
>