Break up json file for a given version

[toddjordan]

Currently the script turns the doc for a given ember version into one big json file ~1.1MB. This is pretty big for people on mobile, or who have limited bandwidth. We'll need to break up the data into pieces, probably to be lazy loaded by the UI.

TODO: Create a proposal for smaller sub-files.

[acorncom]

probably to be lazy loaded by the UI

We could do that using ember-concurrency, though adding the add-on just for that one task might be overkill ...

[toddjordan]

yeah, we want to pair quicker load times with the ability to offline browse for a given version. Unsure if this is MVP. Will seek some direction.

[sivakumar-kailasam]

@toddjordan along with breaking up the json, how about we have service workers cache the last visited api version's content?

[toddjordan]

I think since the data is static, we can rely somewhat on basic browser http caching. That's my hope to start, especially since service workers are a chrome/firefox only thing at this point

[acorncom]

@sivakumar-kailasam I'd be inclined to leave service worker caching stuff until after MVP (if you want to write up an issue with your thoughts that'd be great though). Better to get it launched first before we start playing with fanciness ;-)

[toddjordan]

Talked to @tomdale again and have a proposal in my head.

Right now this project transforms the yuidoc output into a giant list of classes/modules per project. We should be able to easily turn each list item into a file.

something like project/version/type/name

in each version directory we should also put a manifest file, that will list all files contained within the version. This will be to guide the client into what it needs to be downloading in the background.

We probably will do a service worker/app cache implementation. I'll write up tasks for these things.

For this task, we need to update the script to divide up the output into a file hierarchy as described, and then create the file listing all of them.

[sivakumar-kailasam]

@toddjordan On the manifest files, I wonder if having two manifest files will suffice,

1. One at the root level which contains info on available ember & ember data versions. eg., api-manifest.json

   {
   "Ember": [ 
         { "2.11" : "S3_URL_TO_VERSION_MANIFEST"} 
   ],
   "Ember Data": [ 
         { "2.11" : "S3_URL_TO_VERSION_MANIFEST"} 
   ],
   }

2. Another at the project's version directory level. eg., ember-2.11-manifest.json

   {
      "namespaces": [ { "Ember.FEATURES": "URL_TO_NAMESPACE_JSON" } ],
      "modules": [ {"ember-debug": "URL_TO_MODULE_JSON"} ],
      "classes": [ {"Ember.Engine" : "URL_TO_CLASS_JSON"} ] 
   }

[toddjordan]

sounds good!

[toddjordan]

@sivakumar-kailasam I've got some ideas for the contents of the manifest file, based on what we need to load the nav menu. I'll write up thoughts in a separate issue.