dojo/text! loader plugin resilient to failure?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

dojo/text! loader plugin resilient to failure?

neekfenwick
Can dojo/text.js be made fault tolerant?

I'm looking at loading a .json config file as our application loads.  
It's replacing config that used to be in our dojoConfig.js file.  So
previously, this config was always available and code could
synchronously use it, e.g.

define([ 'dojo/_base/config' ], function (config) {
     // use config.OurCustomConfig here
});

Now I'm moving this config into an external file but always want to load
it during app startup. I could do this:

define([ 'dojo/text!resources/config.json' ], function (conf) {
     conf = JSON.parse(conf);
     // use conf here
});

However from what I see in dojo/text.js if the load fails for whatever
reason (file missing or server misconfiguration) the request() call made
in text.js has no error handler.  This will cause our app to fail to
load, as a result of the dojo/text! dependency failing to resolve.

As a relative newbie to AMD loader plugins, here's my bare bones attempt
on dojo 1.12.1:

diff --git a/text.js b/text.js
index 9a4839e..22251f5 100644
--- a/text.js
+++ b/text.js
@@ -5,7 +5,10 @@ define(["./_base/kernel", "require", "./has",
"./has!host-browser?./request"], f
      var getText;
      if(has("host-browser")){
          getText= function(url, sync, load){
-            request(url, {sync:!!sync, headers: { 'X-Requested-With':
null } }).then(load);
+            request(url, {sync:!!sync, headers: { 'X-Requested-With':
null } }).then(load, function(err) {
+                console.error('Error loading ' + url + ': ', err);
+                load(null);
+            });
          };
      }else{
          // Path for node.js and rhino, to load from local file system.

So basically there's now an error handler on the request() that invokes
the load() function with a null value.  This is returned as the 'value'
of the loaded dojo/text! plugin, and my code can react to that.

Would this patch be acceptable? (probably without the console.error?)

My reason for wanting to use the AMD loader as the mechanism, rather
than doing my own xhr GET, is that the example module above is actually
a dependency of a core config module of ours, which then instantiates
the rest of the UI using this config, so I'd like a tidy way of loading
the config asynchronously as this module loads without messing with the
current bootstrapping code of our app.  It's just the fault tolerance
that currently can lead to a 'dead' app that I'd like to avoid.

Nick

--
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
|  
Report Content as Inappropriate

Re: dojo/text! loader plugin resilient to failure?

dylanks
Nick,

Please go ahead and submit a PR for this, and if it passes tests and
doesn't raise any major objections, then we'll land this for 1.13. Thanks!

Regards,
-Dylan

on 3/20/17, 02:17 (GMT-07:00) Nick Fenwick said the following:

> Can dojo/text.js be made fault tolerant?
>
> I'm looking at loading a .json config file as our application loads.  
> It's replacing config that used to be in our dojoConfig.js file.  So
> previously, this config was always available and code could
> synchronously use it, e.g.
>
> define([ 'dojo/_base/config' ], function (config) {
>      // use config.OurCustomConfig here
> });
>
> Now I'm moving this config into an external file but always want to load
> it during app startup. I could do this:
>
> define([ 'dojo/text!resources/config.json' ], function (conf) {
>      conf = JSON.parse(conf);
>      // use conf here
> });
>
> However from what I see in dojo/text.js if the load fails for whatever
> reason (file missing or server misconfiguration) the request() call made
> in text.js has no error handler.  This will cause our app to fail to
> load, as a result of the dojo/text! dependency failing to resolve.
>
> As a relative newbie to AMD loader plugins, here's my bare bones attempt
> on dojo 1.12.1:
>
> diff --git a/text.js b/text.js
> index 9a4839e..22251f5 100644
> --- a/text.js
> +++ b/text.js
> @@ -5,7 +5,10 @@ define(["./_base/kernel", "require", "./has",
> "./has!host-browser?./request"], f
>       var getText;
>       if(has("host-browser")){
>           getText= function(url, sync, load){
> -            request(url, {sync:!!sync, headers: { 'X-Requested-With':
> null } }).then(load);
> +            request(url, {sync:!!sync, headers: { 'X-Requested-With':
> null } }).then(load, function(err) {
> +                console.error('Error loading ' + url + ': ', err);
> +                load(null);
> +            });
>           };
>       }else{
>           // Path for node.js and rhino, to load from local file system.
>
> So basically there's now an error handler on the request() that invokes
> the load() function with a null value.  This is returned as the 'value'
> of the loaded dojo/text! plugin, and my code can react to that.
>
> Would this patch be acceptable? (probably without the console.error?)
>
> My reason for wanting to use the AMD loader as the mechanism, rather
> than doing my own xhr GET, is that the example module above is actually
> a dependency of a core config module of ours, which then instantiates
> the rest of the UI using this config, so I'd like a tidy way of loading
> the config asynchronously as this module loads without messing with the
> current bootstrapping code of our app.  It's just the fault tolerance
> that currently can lead to a 'dead' app that I'd like to avoid.
>
> Nick
>
--
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/
Loading...