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 <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
