externalize views logic

[jonschlinkert]

@doowb I have an idea for how to simplify a lot of template.

we can start by externalizing most of the .create() logic and related lookup stuff to another lib, like view-cache or views-cache.

loaders

I realized today that template subtypes and templates don't "use" loaders, they are loaders. From that frame of reference, it seems that we should be able to dramatically reduce the logic in the create method by doing the following in view-cache:
1. Add a .createLoader() method (or whatever it should be called) to loader-cache that returns a function bound to a loader composition and loader type. e.g. "create an async loader, composed of [a, b, c] loaders".
2. this .createLoader() method would either a) call .compose() twice: first in the .create() method then a second invocation in the template subtype's method (basically compose a new loader from the type's loader plus additional loaders that may be defined in the subtype), then call .load(). Or, b) .createLoader() can curry arguments from the .create() method to the subtype. The first has the advantage of storing a loader on the loaders object with the name of the subtype, allowing template subtypes to be composed of other template subtypes :). the second is most likely faster.

get/set/lookup methods

We would also be able to isolate any convenience methods related to getting, setting or finding templates, and do more specific unit testing.

collections

seems like it would be easier to see how collections would be created

thoughts?

[jonschlinkert]

okay, here is a potential starting point:

I think we should get rid of the .matchLoader() method, it seems to complicate everything. I think we should instead consider the following:

1. change the .load() method so that it requires a loader function or the name of the loader or composition to use. and/or
2. in addition to storing loaders and compositions by name as we do currently, store all loader functions anonymously on a single array so that, by default, when .load() is called and a starting loader, composition or function is not passed, we run the full loaders stack on the arguments in the order in which the loaders were defined.

Examples:

// run the full loader stack 
app.load('package.json');
// `parse` is the loader composition to use
app.load('package.json', 'parse');
// or
app.load('package.json', ['parse']);
// or 
app.load('package.json', ['parse'], function() {
  // do stuff
});

Or, we:

• add a .loader() method that returns a .load() function based on the given options, or
• just change the .load() method so it returns a function to do the loading.

I think I like either these last solutions best because potentially removes a lot of logic related to figuring out arguments:

var load = app.loader(['whatever']);
load('foo');

or

var load = app.load(['whatever']);
load('foo');

or

var load = app.load(['whatever'], function(a, b, c) {
  // do stuff 
});
load('foo');