AMD alternative to dojo.exists for testing to see if a module is loaded

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

AMD alternative to dojo.exists for testing to see if a module is loaded

sg3235
In pre-AMD days, one could use dojo.exists to determine if a module had been loaded.  Now that we’re using AMD, it doesn’t seem like dojo.exists (or lang.exists) applies as it simply looks for an object in dojo.global, which doesn’t include AMD modules.  Is there a way to determine whether or not an AMD module has been loaded without loading it.

The reason I ask is because it turns out to be a very specialized case where an IBM product is trying to build a layer file on the fly.  It supplies a list of “excludes” for things that it finds have already been loaded.  Unfortunately, that ability seems to be limited to things that are still being loaded using the legacy loader and we’re getting multiple defines for things that are AMD.

Steve

--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: AMD alternative to dojo.exists for testing to see if a module is loaded

Karl Tiedt
Not sure I follow the logic in this, require() wont load a module twice... so there is really minimal gain here at run time, however you should be able to explore the properties of the require global (granted this may be different between dojo's loader and RequireJS for example... you should find your answers there.

-Karl Tiedt

On Sat, Jul 18, 2015 at 2:14 PM, Stephen Gevers <[hidden email]> wrote:
In pre-AMD days, one could use dojo.exists to determine if a module had been loaded.  Now that we’re using AMD, it doesn’t seem like dojo.exists (or lang.exists) applies as it simply looks for an object in dojo.global, which doesn’t include AMD modules.  Is there a way to determine whether or not an AMD module has been loaded without loading it.

The reason I ask is because it turns out to be a very specialized case where an IBM product is trying to build a layer file on the fly.  It supplies a list of “excludes” for things that it finds have already been loaded.  Unfortunately, that ability seems to be limited to things that are still being loaded using the legacy loader and we’re getting multiple defines for things that are AMD.

Steve

--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest



--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: AMD alternative to dojo.exists for testing to see if a module is loaded

sg3235
I’m not concerned about require loading the module twice, I’m concerned with a layer file that contains a module that’s already been loaded.  When the layer file is processed, we get a multiply defined error message.   The layer file is being built on the fly and the request that’s being made has a list of modules to exclude from the layer.  This works for legacy modules.  I couldn’t find anything in the “require” documentation that indicated which modules had been loaded.

Steve

On Jul 18, 2015, at 4:17 PM, Karl Tiedt <[hidden email]> wrote:

Not sure I follow the logic in this, require() wont load a module twice... so there is really minimal gain here at run time, however you should be able to explore the properties of the require global (granted this may be different between dojo's loader and RequireJS for example... you should find your answers there.

-Karl Tiedt

On Sat, Jul 18, 2015 at 2:14 PM, Stephen Gevers <[hidden email]> wrote:
In pre-AMD days, one could use dojo.exists to determine if a module had been loaded.  Now that we’re using AMD, it doesn’t seem like dojo.exists (or lang.exists) applies as it simply looks for an object in dojo.global, which doesn’t include AMD modules.  Is there a way to determine whether or not an AMD module has been loaded without loading it.

The reason I ask is because it turns out to be a very specialized case where an IBM product is trying to build a layer file on the fly.  It supplies a list of “excludes” for things that it finds have already been loaded.  Unfortunately, that ability seems to be limited to things that are still being loaded using the legacy loader and we’re getting multiple defines for things that are AMD.

Steve

--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest


--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest


--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: AMD alternative to dojo.exists for testing to see if a module is loaded

dylanks
With Dojo 1.x's AMD loader, you can introspect things like
require.modules, require.cache, require.defQ, require.execQ, etc. Note
that a build may optimize these away, so you'll want to specify
staticHasFeatures for dojo-publish-privates to true.

There are also the micro event API (require.on/require.signal) for
listening to loader events, and the trace API (require.tract,
require.trace.on, etc.) to listen for other events, e.g. injecting,
defining, or executing a module. To use the latter, you'll need to make
sure it's not removed by your build by setting the dojo-trace-api to
true within the list of staticHasFeatures.

These topics and more on debugging module loading are covered in
https://dojotoolkit.org/reference-guide/1.10/loader/amd.html , or within
the SitePen Dojo 202 workshop (
https://www.sitepen.com/workshops/index.html )

Regards,
-Dylan

on 7/18/15, 14:36 (GMT-07:00) Stephen Gevers said the following:

> I’m not concerned about require loading the module twice, I’m concerned
> with a layer file that contains a module that’s already been loaded.
>  When the layer file is processed, we get a multiply defined error
> message.   The layer file is being built on the fly and the request
> that’s being made has a list of modules to exclude from the layer.  This
> works for legacy modules.  I couldn’t find anything in the “require”
> documentation that indicated which modules had been loaded.
>
> Steve
>
>> On Jul 18, 2015, at 4:17 PM, Karl Tiedt <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Not sure I follow the logic in this, require() wont load a module
>> twice... so there is really minimal gain here at run time, however you
>> should be able to explore the properties of the require global
>> (granted this may be different between dojo's loader and RequireJS for
>> example... you should find your answers there.
>>
>> -Karl Tiedt
>>
>> On Sat, Jul 18, 2015 at 2:14 PM, Stephen Gevers
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     In pre-AMD days, one could use dojo.exists to determine if a
>>     module had been loaded.  Now that we’re using AMD, it doesn’t seem
>>     like dojo.exists (or lang.exists) applies as it simply looks for
>>     an object in dojo.global, which doesn’t include AMD modules.  Is
>>     there a way to determine whether or not an AMD module has been
>>     loaded without loading it.
>>
>>     The reason I ask is because it turns out to be a very specialized
>>     case where an IBM product is trying to build a layer file on the
>>     fly.  It supplies a list of “excludes” for things that it finds
>>     have already been loaded.  Unfortunately, that ability seems to be
>>     limited to things that are still being loaded using the legacy
>>     loader and we’re getting multiple defines for things that are AMD.
>>
>>     Steve
>>
>>     --
>>     Dojo Toolkit: http://dojotoolkit.org/
>>     Tutorials: http://dojotoolkit.org/documentation/
>>
>>     [hidden email]
>>     <mailto:[hidden email]>
>>     To unsubscribe, visit:
>>     http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>
>>
>> --
>> Dojo Toolkit: http://dojotoolkit.org/
>> Tutorials: http://dojotoolkit.org/documentation/
>>
>> [hidden email]
>> <mailto:[hidden email]>
>> To unsubscribe, visit:
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>

--
Dylan Schiemann
SitePen, Inc.
Dojo workshops in the US, Canada, and Europe:
http://www.sitepen.com/workshops/
http://www.sitepen.com/

--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Co-Founder, Dojo Toolkit
CEO, SitePen, Inc.  http://www.sitepen.com/