types

[jonschlinkert]

Background

Currently, in templates, assemble and other base app, we have the convention of using isApp, isView and so on to identify the "instance type", so that plugins will only be used on certain instances.

Proposal

I propose that we implement one or two methods and associated properties here, in base-plugins, for checking instance "types". I think these methods belong here since "smart plugins" can't be used without this plugin, thus isApp or similar labels are useless otherwise.

Example

• .is {Function}: Currently we use the .is method to add a type to an instance. I think this can stay the same, but we can also allow an array of strings to be passed, like app.is(['views', 'collection'])
• ._is {Array}: we should add an ._is array for storing names passed to .is.
• .isType {Function}: this method would take a string or array of strings and return true if an instance has any of the given strings on the ._is array. It would also return true for isType('app') when no other types are defined.

@doowb, anyone else, thoughts?

[jonschlinkert]

another idea is to add an isApp getter/setter that would return true if either:

• isApp was explicitly defined (as true), or
• no other types were explicitly defined

I think that would be good to have directly in base instead of here. the more I think about the more I wonder if the other .is stuff I proposed belongs in base as well... hmm

[doowb]

I like these ideas. I also think that it should be on base directly since we've recently had a couple of issues with the examples not working because they don't include {isApp: true}. I'm assuming that's the reasoning for:

It would also return true for isType('app') when no other types are defined.

Would the ._is array be cumulative or would it get replaced on the child instance? If it's replaced, maybe we can have additional methods that provide conveniences for working with the ._is array:

• .isAlso Adds additional types to the ._is array.
• .isNot Removes types from the ._is array.