Loading

edited August 2013 in Enyo 2
Hello - my app has a few different versions/sku's and currently the source directory is structured as so:
source/
  package.js
   ....base js files...
  /appSKU1
     package.js
     ....appSKU1 js files...
  /appSKU2
     package.js
     ....appSKU2 js files...
On load of the app it uses the base kinds I define + kinds from the particular sku it is set for. Currently I just comment out a line in my top level package.js like so before running/building the app:
//this is when SKU1 is needed:
enyo.depends(
 ...js files...,
 "appSKU1/package.js"//,
 //"appSKU2/package.js"  <- comment out this line when needing only appSKU1
);</code>
My question is what's the right way to more dynamically load the sku specific package on startup? Or is there generally a better approach so that builds work properly too...?

Comments

  • edited August 2013
    In my index.html (or debug.html) file, I do something like this:
    
    init = function(){
    
    	document.getElementById("status").innerHTML = "Loading libraries and fonts.";		
    	setTimeout(function(){enyo.load("/rootFolder/package.js");}, 200);
    
    	setTimeout(function(){document.getElementById("status").innerHTML = "Proceeding to app."}, 1000);		
    }
    
    The attribute has a "onload=setTimeout(this.init,10);" in it. I imagine you could do some processing before the enyo.load line above to determine which package file you want to load? Of course, I have the base enyo.js file being loaded in before this part of code executes.
  • Thanks for that & it sounds like it would work, but ideally I was hoping for something that ties into the standard package loading enyo does on startup. Something that happens before initiating the actual app so there's no unnecessary delays or timeout assumptions that need to be made. I'm not familiar with the enyo loading specifics so maybe this doesn't exactly make sense but my understanding is that enyo loads everything from the package.js file before initiating the app. If that's relatively the case then something like an enyo.addPackageToStartup("path to my custom package") call that would load the package on startup as if it were statically specified in the app's default package.js might do the trick.

    I guess for now I could add logic in my index file that determines the base package.js file to load which would then be unique for each sku.
  • I believe enyo.load() accomplishes the same :) You don't have to add the setTimeout. I use it not to lock up the UI and to provide some status messages (i removed those parts from code sample) while all the packages load.
  • edited September 2013
    I played around with it a bit & I don't think that's the case unfortunately. I found that the kinds loaded in an enyo.load aren't available immediately on app startup (specifically in my app's standard create method). This was the best way I could find with this approach:
    		
    			var cb = function() {
    				myApp.setup();
    			}
    			enyo.load("path to sku package.js", cb);
    						
    
    Where myApp is a global reference to the app, ie something like:
    	
    		
    			var myApp = new App({fit:true});
    			myApp.write();
    		
    	
    
    So basically instead of a setTimeout you can leverage enyo.load's callback parameter to know when it loads the package & the app can then proceed with setup. You might prefer this to your current approach since I think this will give the same effect but without timeout length assumptions needed?

    However there are still a couple disappointments for me, I think:

    1) This is done after enyo loads the app & I'm looking for something that is done before that. There's a noticeable difference in startup (for those of us that are super anal).

    2) I'm guessing this isn't going to work well with a build.
  • in your App.js, use start:false (or is it autostart:false), and then manually start it in a JS file that loads your app...in my case, I have an index.js file that starts it and is in the package.js that is enyo.load'ed - i.e., app doesn't start in index.html and hence the timeout isn't for that purpose. For your purpose, you can safely remove the setTimeout.

    I think this meets requirement #1 but perhaps I'm not explaining it well... Re: #2, for me, it works fine with build but I guess in your case, you'd have to figure out if you want to include all the sku packages into your build or not - by default it will.
  • Ah I see, but looks like that's only when using the new enyo.Application kind. I've been shying away from the mvc stuff, seems a bit too undocumented & constantly changing so far. Well I'll give it a try since they say they're close.

    Oh I guess I am pretty ignorant of the way the build process works, glad to hear it should work, I'll take a look.

    Sounds like this should get me to where I want to be, I'll report back once I have time to test it out.

    Thanks very much for your help!!
  • edited September 2013
    Well doesn't look like this approach will pan out the way I'd like. Still a couple issues:

    1) autostart or instead just using .renderInto rather than .write to start the app when loading is done works, but there is a small noticeable delay in loading this way.

    2) Using enyo.load in a deployed version is requiring that I copy over the package.js/linked .js files, ie they don't get added to my app.js compilation. Doesn't sound like you have this issue so I'm confused about that - maybe I have an out of date packager/build thingy?

    The most ideal way I've found, but also the biggest hack is to add a variable in my top level package.js file to specify the app sku being run/built & then check it for which packages to load. For example in package.js something like this:
    var sku = "sku1";
    enyo.depends(
      "base file1.js",
      "base file2.js",
      ...
      sku == "sku1" ? "sku1.js" : "",
      sku == "sku2" ? "sku2.js" : ""
    );
    
  • The .write() feature is VERY deprecated as it doesn't work for any of the constrained runtime environments, like Windows 8 apps or Chome store apps. I've been trying to make sure all of our samples are switched over to using renderInto.
  • Good to know, thanks. In that case I can better live with the bit of delay at startup with renderInto.
Sign In or Register to comment.