Discuss
  • A question about Loader baseURL

A question about Loader baseURL

# Shijun He (13 years ago)

It seems current loader spec is so simple and I'm full of confusion of baseURL props.

// lib/a.js

System.baseURL // "lib/a.js" ?? System.load('b.js', ...) // I suppose this should load "lib/b.js", right?

var myLoader = new Loader(System, { baseURL: 'mypath/c.js' , fetch:myFetch })

myLoader.baseURL // 'mypath/c.js' or 'lib/mypath/c.js' or any other value? myLoader.load('b.js' ...) // load 'lib/mypath/b.js' or 'lib/b.js' ?

function myFetch(relURL, baseURL, ...) { relURL // 'b.js' or 'mypath/b.js' or any other value? baseURL // ? }

and what happens if I call myLoader in other code for example which url is '/otherpath/' ?

-- hax

# Sam Tobin-Hochstadt (13 years ago)

On Mon, Aug 27, 2012 at 6:32 AM, Shijun He <hax.sfo at gmail.com> wrote:

It seems current loader spec is so simple and I'm full of confusion of baseURL props.

// lib/a.js

System.baseURL // "lib/a.js" ??

No, the base url will be an absolute URL, like 'example.com/lib/a.js'.

System.load('b.js', ...) // I suppose this should load "lib/b.js", right?

Yes.

var myLoader = new Loader(System, { baseURL: 'mypath/c.js' , fetch:myFetch })

myLoader.baseURL // 'mypath/c.js' or 'lib/mypath/c.js' or any other value?

'mypath/c.js', which is what you provided as the 'baseURL'.

myLoader.load('b.js' ...) // load 'lib/mypath/b.js' or 'lib/b.js' ?

Neither -- this invokes the fetch hook with relative url 'b.js', and the base url 'mypath/c.js' -- it's up to the fetch hook to determine what to do with it. But 'lib' isn't in either of those arguments (although myFetch might contain a reference to System.baseURL).

function myFetch(relURL, baseURL, ...) { relURL // 'b.js' or 'mypath/b.js' or any other value? baseURL // ? }

See above.

and what happens if I call myLoader in other code for example which url is '/otherpath/' ?

I don't understand what you're asking here.

# Shijun He (13 years ago)

On Mon, Aug 27, 2012 at 8:10 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:

System.baseURL // "lib/a.js" ??

No, the base url will be an absolute URL, like 'example.com/lib/a.js'.

So in /lib/b.js , System.baseURL will return a diff result "example.com/lib/b.js" ?

var myLoader = new Loader(System, { baseURL: 'mypath/c.js' , fetch:myFetch })

myLoader.baseURL // 'mypath/c.js' or 'lib/mypath/c.js' or any other value?

'mypath/c.js', which is what you provided as the 'baseURL'.

myLoader.load('b.js' ...) // load 'lib/mypath/b.js' or 'lib/b.js' ?

Neither -- this invokes the fetch hook with relative url 'b.js', and the base url 'mypath/c.js' -- it's up to the fetch hook to determine what to do with it. But 'lib' isn't in either of those arguments (although myFetch might contain a reference to System.baseURL).

So how do myLoader know what is the URL of the caller?! I mean:

I want:

/a/*.js myLoader.load('test.js') // load /a/test.js

/b/*.js myLoader.load('test.js') // load /b/test.js

But myFetch get the identical args: ('test.js', myLoader.baseURL)

HOW can myFetch know the correct URL? (Holding System.baseURL seems useless in this case.)

and what happens if I call myLoader in other code for example which url is '/otherpath/' ?

I don't understand what you're asking here.

See above :)

-- hax

# Sam Tobin-Hochstadt (13 years ago)

On Mon, Aug 27, 2012 at 10:07 AM, Shijun He <hax.sfo at gmail.com> wrote:

On Mon, Aug 27, 2012 at 8:10 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:

System.baseURL // "lib/a.js" ??

No, the base url will be an absolute URL, like 'example.com/lib/a.js'.

So in /lib/b.js , System.baseURL will return a diff result "example.com/lib/b.js" ?

This depends on how you're loading "b.js".

var myLoader = new Loader(System, { baseURL: 'mypath/c.js' , fetch:myFetch })

myLoader.baseURL // 'mypath/c.js' or 'lib/mypath/c.js' or any other value?

'mypath/c.js', which is what you provided as the 'baseURL'.

myLoader.load('b.js' ...) // load 'lib/mypath/b.js' or 'lib/b.js' ?

Neither -- this invokes the fetch hook with relative url 'b.js', and the base url 'mypath/c.js' -- it's up to the fetch hook to determine what to do with it. But 'lib' isn't in either of those arguments (although myFetch might contain a reference to System.baseURL).

So how do myLoader know what is the URL of the caller?! I mean:

I want:

/a/*.js myLoader.load('test.js') // load /a/test.js

/b/*.js myLoader.load('test.js') // load /b/test.js

But myFetch get the identical args: ('test.js', myLoader.baseURL)

HOW can myFetch know the correct URL? (Holding System.baseURL seems useless in this case.)

load is a method, which can be called anywhere. Having it depend on a dynamically-scoped bit of information such as the url of the file that the method is called in, would make using loaders much harder to understand.

This is just like current browser behavior when you insert a <script src="test.js"> tag -- "test.js" is looked up relative to the URL of

the page, not relative to the URL of the js file that does the dom manipulation.

# Kevin Smith (13 years ago)

So how do myLoader know what is the URL of the caller?! I mean:

I want:

/a/*.js myLoader.load('test.js') // load /a/test.js

/b/*.js myLoader.load('test.js') // load /b/test.js

But myFetch get the identical args: ('test.js', myLoader.baseURL)

This is a point that I've been meaning to bring up as well. Thanks for illustrating it.

# Shijun He (13 years ago)

On Mon, Aug 27, 2012 at 10:14 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:

So in /lib/b.js , System.baseURL will return a diff result "example.com/lib/b.js" ?

This depends on how you're loading "b.js".

Could explain more about that? I suppose b.js is loaded by system loader.

I want:

/a/*.js myLoader.load('test.js') // load /a/test.js

/b/*.js myLoader.load('test.js') // load /b/test.js

But myFetch get the identical args: ('test.js', myLoader.baseURL)

HOW can myFetch know the correct URL? (Holding System.baseURL seems useless in this case.)

load is a method, which can be called anywhere. Having it depend on a dynamically-scoped bit of information such as the url of the file that the method is called in, would make using loaders much harder to understand.

I don't think so. Loader is a very special util, and I believe most coders expect the behavior I described, and that also match the behavior of System loader (what I confirmed in early post), or require in CommonJS.

This is just like current browser behavior when you insert a <script src="test.js"> tag -- "test.js" is looked up relative to the URL of the page, not relative to the URL of the js file that does the dom manipulation.

That's WHY we need loader in JS, not script tag in HTML.

And current ES3/5 loaders are all trying to solve the base URL by tricks (such as check script.readystate and find which script is running and get the right baseURL)

-- hax

# Kevin Smith (13 years ago)

(This pretty much just repeats what hax said...)

load is a method, which can be called anywhere. Having it depend on a dynamically-scoped bit of information such as the url of the file that the method is called in, would make using loaders much harder to understand.

Perhaps, but I fear this will limit the usefulness of dynamic loading to absolute URLs. If a programmer writes:

System.load("my-file.js", Module => { ... });

It's highly unlikely that they care about the URL of the page or the baseURL of the current loader or any other "remote knowledge" like that. It's just not modular : )

This is just like current browser behavior when you insert a `<script

src="test.js">` tag -- "test.js" is looked up relative to the URL of the page, not relative to the URL of the js file that does the dom manipulation.

: ) Yes, and that behavior makes loading anything other than absolute URLs, um, "tricky".

# Shijun He (13 years ago)

Example:

== my.js ==

var myLoader = new Loader(System, {fetch: myFetch} function myFetch(relURL, baseURL, ...) {...}

myLoader.load('a/a.js', ...)

== a/a.js == import x from 'a/a.js' // developer means to load a/a/a.js ...

As I understand, imports in a/a.js (what in this case also import another 'a/a.js' which should be resolve to 'a/a/a.js') will also delegate to myLoader, so it is obviously wrong if myFetch is invoked with two identical arguments.

-- hax

# Sam Tobin-Hochstadt (13 years ago)

On Mon, Aug 27, 2012 at 11:38 PM, Shijun He <hax.sfo at gmail.com> wrote:

Example:

== my.js ==

var myLoader = new Loader(System, {fetch: myFetch} function myFetch(relURL, baseURL, ...) {...}

myLoader.load('a/a.js', ...)

== a/a.js == import x from 'a/a.js' // developer means to load a/a/a.js ...

Right, and the sensible way to combine the baseURL 'example.com/a/a.js' and the relURL 'a/a.js' is to produce 'example.com/a/a/a.js', which is exactly what you want in this case.

As I understand, imports in a/a.js (what in this case also import another 'a/a.js' which should be resolve to 'a/a/a.js') will also delegate to myLoader,

Exactly.

so it is obviously wrong if myFetch is invoked with two identical arguments.

I don't see why that's wrong at all.

# Shijun He (13 years ago)

On Tue, Aug 28, 2012 at 7:44 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:

As I understand, imports in a/a.js (what in this case also import another 'a/a.js' which should be resolve to 'a/a/a.js') will also delegate to myLoader,

Exactly.

so it is obviously wrong if myFetch is invoked with two identical arguments.

I don't see why that's wrong at all.

For load('a/a.js') in my.js, myFetch is invoked with: relURL='a/a.js' baseURL = System.baseURL = '/path/my.js'

For import x from 'a/a.js', myFetch is also invoked with: relURL='a/a.js' baseURL = System.baseURL = '/path/my.js'

How myFetch can resolve identical envokes to different resouce?

# Shijun He (13 years ago)

For load('a/a.js') in my.js, myFetch is invoked with: relURL='a/a.js' baseURL = System.baseURL = '/path/my.js'

For import x from 'a/a.js', myFetch is also invoked with: relURL='a/a.js' baseURL = System.baseURL = '/path/my.js'

typo, both System.baseURL should read as myLoader.baserURL