Skip to content

App Boilerplate: helpers #14

Closed
ErisDS opened this Issue Feb 10, 2014 · 9 comments

4 participants

@ErisDS
Ghost member
ErisDS commented Feb 10, 2014

Want to leave this open whilst we're building out example apps and getting the platform into a usable state.

We have the backbone-events style JSON syntax for filters, would it make sense to add this for helpers too?

I'm referring to the ability to do:

MyApp = App.extend({
    helpers: {
       myHelper: 'myHelper'
    },
    myHelper: function () {},
});

I'm not sure if the same syntax makes sense, because the name of the helper is going to be the same as the name of the function. Also, how would we distinguish between async and non-async helpers?

@ErisDS ErisDS referenced this issue in TryGhost/Ghost Feb 11, 2014
Closed

Ghost Apps & the Ghost Developer Kit #1474

@jgable
Ghost member
jgable commented Feb 28, 2014

I think we've got a couple options here:

  1. have an asyncHelpers and helpers hash (kinda not very "one way to do things")
  2. have async helpers use a special naming convention like myHelper: 'asyncMyHelper'
  3. have all helpers be async and we just wrap them in a when.resolve(..) when registering

I think 3 is easiest to implement and develop against so I vote for it. 2 would be my second choice.

@AJ-Acevedo

Option 3 sounds ideal. What would be the disadvantage (if any) of going with option 3?

@jgable
Ghost member
jgable commented Mar 3, 2014

The only thing I can come up with is that it's a small, maybe even tiny, performance penalty to have to wrap everything in when.resolve.

@ErisDS
Ghost member
ErisDS commented Mar 7, 2014

@jgable the other downside is that async helpers are a creation of express-hbs, and unfortunately at present don't work with subexpressions - having everything be async could potentially result in some unexpected results.

I'm not particularly sold that this is even a good idea. It makes sense for filters because they are such a fundamental part of apps - but the more I think about this the less I think it makes sense.

I get the feeling it's a pre-optimisation, and that if we see a need for it in future we could add it?

Would love to hear what other people's feelings are on it though.

@jgable
Ghost member
jgable commented Mar 7, 2014

@ErisDS I agree about the reliance on a non-standard handlebars feature from express-hbs.

On the pre-optimization (yeah, that's a z in there) front, I'd also agree. None of the ideas I've had for apps have required extra helpers yet.

@ErisDS
Ghost member
ErisDS commented Mar 7, 2014

to-may-to to-mah-to :dancers:

Let's leave this then, I'll close it unless someone else comes up with a different perspective :)

@ErisDS ErisDS closed this Mar 7, 2014
@k-j-kleist

Has somebody actually created a handlebars helper using an app?

https://github.com/TryGhost/Ghost/blob/master/core/server/apps/proxy.js#L62 seems to indicate it should be possible. However this code does not work:

'use strict';

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

MyApp = App.extend({

    initialize: function () {
        console.log('MyApp: initialize()');
    },

    install: function () {
        console.log('MyApp: install()');
    },

    uninstall: function () {
        console.log('MyApp: uninstall()');
    },

    activate: function () {
        console.log('MyApp: activate()');
    },

    deactivate: function () {
        console.log('MyApp: deactivate()');
        },

    // https://github.com/TryGhost/Ghost/blob/master/core/server/apps/proxy.js#L62

    // "package.json":
    //
    // "ghost": {
    //    "permissions": {
    //        "helpers": ["fb_post_url"]
    //    }
    // }

    helpers: {
        fb_post_url: 'getFbPostUrl'
    },

    getFbPostUrl: function(fb_post_url) {
            return('http://example.com/foo/bar/baz');
    }

});

module.exports = MyApp;

I'd hate to abuse config.js as often suggested by posts like this:

http://zackehh.com/safely-creating-custom-handlebars-helpers/

@ErisDS
Ghost member
ErisDS commented May 24, 2015

This issue was closed because this version of the syntax was proposed and then rejected ;)

Therefore the way to register a helper is via the app proxy object as part of the activate function:

activate: function () {
    console.log('MyApp: activate()');
    this.app.helpers.register('fb_post_url', this.getFbPostUrl);
}

Prolly worth adding that to the docs if you have a second :+1:

@k-j-kleist

Works like a charm (using "this.ghost" instead of "this.app"), thanks!

I've updated https://github.com/TryGhost/Ghost/wiki/Apps-Getting-Started-for-Ghost-Devs accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.