App Boilerplate: Do we need .App? and other extendable base apps?

[ErisDS]

Another discussion point.

At the moment, the first line of an app will look something like:

var App = require('ghost-app').App;

Arguably, it would be nicer to have:

var App = require('ghost-app');

However, the reason for the extra .App is the idea that we may have multiple base apps which you can extend to build an app. As per @jgable's original implementation, there were a number of potential examples such as FilterPlugin which has the addtitional syntax for registering filters mentioned in #6 and DatabasePlugin which has tools for adding and removing tables.

So the question is do we need these additional boilerplates? And if we do, do we always have to have .App or can we get around it?

In terms of the boilerplates, many of them are in place to do hardwork that the GDT should make much easier.. so perhaps they are less necessary.

On the flip-side, having boilerplates which provide structure and syntax for doing certain tasks is... well... epic! It is absolutely in line with most of our core principles for apps:

• consistency, consistency, consistency
• providing 1 clear way to do things
• minimal boilerplate
• sensible, manageable structure
• easily extensible

Thoughts?

[simonexmachina]

I think .App is fine, avoids painting ourselves into a corner.

[jgable]

I personally prefer exporting all the base types individually, but we can achieve a similar thing with a static property on the App class.

/* snip ... App.prototype declarations */

App.FilterApp = require('./FilterApp');

module.exports = App;

Then change the index.js to just export the App like you mentioned in the OP. Then it would be used like this

var GhostApp = require('ghost-app'),
    FilterApp = GhostApp.FilterApp;

// Normal App
var MyApp = GhostApp.extend({ ... });

// Filter App
var MyFilterApp = FilterApp.extend({ ... });

I guess the downside is that we pass all that extra stuff with the GhostApp, but it shouldn't be that heavy.

[sethvincent]

It would be neat if higher level base apps/boilerplates could live in separate repos. So it would be something like:

var MyFilterApp = require('ghost-app-filter');

ghost-app-filter in turn depends on the base ghost-app.

It would be a similar pattern as grunt uses for grunt plugins, or yeoman uses for yo generators.

The bonus would be that it simplifies usage of each base app. The bummer might be that there are multiple repos, but that might not actually be a problem.

[jgable]

I actually like @sethvincent's idea, but that seems like a lot of extra project boilerplate for not a lot of benefit other than modularity.

[JohnONolan]

Subjectively (just throwing it out there) - multiple boilerplate apps doesn't feel like "one clear way of doing things" to me... is the abstraction a big improvement on the alternative?

[jamesbloomer]

Personally I don't see a problem with adding .App on the end of a require, I've done that many times with different modules.

As to whether it's necessary...
As an app developer I would first want as few decisions as possible, then it's easier to get started. Why not go with the simplest thing and emerge any other needs later? I think it's perfectly acceptable to be agile even with a SDK like this as long as the communication to developers is clear.

[jgable]

@JohnONolan now that you mention it, the abstractions are almost just kind of abstraction masturbation. We could approach this from the opposite direction; expose the most fleshed out class as App and then make the smaller bases exposed some other way.

[ShaneHudson]

Would it be possible/worth doing to have the default boilerplate without the .App and then have the alternative boilerplates as it would be anyway?

For example:

Default app - var App = require('ghost-app');
Database app - var App = require('ghost-app').DatabaseApp;

[jgable]

@ShaneHudson That's kind of what I'm describing. Expose the smaller sub classes as static properties on the main App class.

[ErisDS]

I think we've reached an agreement that having to type .App is not preferred?

I'm wondering whether sub classes or bases are the correct approach, or whether something more similar to mixins is what we want / are achieving. After all we can potentiall extend as many things as we like.