convention for helpers about ember-app-kit

[twokul]

helpers/time.js:

var helperFunction = function() {
  // does stuff
};
export default helperFunction;

And also:

helpers/time => Ember.Handlebars.registerBoundHelper('time', helperFunction);

[machty]

Just thinking out loud here, but in case we want to support the option of people's helper functions in /helpers/**/*.js using registerHelper vs registerBoundHelper (which people will admittedly want to use 90% of the time), we could at some point allow for something like this:

var helperFunction = function() {
  // does stuff
};

helperFunction.raw = true; // use registerHelper

export default helperFunction;

Thoughts?

[stefanpenner]

you can have both a default, and default + named exports.

export unboundHelper;
export default <name of helper>;

if we detect unboundHelper we prioritize it.

[thomasboyt]

• I want to stick to the one file == one export == one module system we have going, seems weird to break that for helpers in particular

• Sticking config on the function could work, or some other kind of configuration object the resolver could handle, i.e.:

  export default { name: "myHelper", fn: myFunction, raw: true }

  (ugly though)

• Do we want to enforce file name == helper name? Bad for people who like camelCase.

[ryanflorence]

My concerns:

1. I believe pretty strongly helpers should be camelCase, if they are dash-erized its not obvious where to go looking in the JS when staring at a template. Dashes, components; camelCase, helper.
2. There are actually three types of helpers, registerHelper, registerBoundHelper, and just helper which can take an Ember.View as the second argument. Anything we do to export something will feel awkward I think.

I'm happy to just have helper files register themselves. Ember.Handlebars.registerHelper and then the ember docs actually mean something.

[machty]

So, I'm working on container-izing helpers with @twokul right now, and just so we're all on the same page, the plan is to have helpers be stored as functions on the container. For bound helpers (most of them), we're splitting the bulk of the registerBoundHelper code into makeBoundHelper, which, given a function, will return a function that can be used as a bound helper and therefore stored on the container. I think this is the right way to go; it'll be up to EAK and any other approaches that make use of the container to determine how and whether a helper is bound vs raw vs whatever, and decide what gets stashed on the container.

(this is me not weighing in on how EAK should expose it; just making it clear what is EAK vs Ember's responsibility. lemme know if i'm craycray)

[machty]

Check out the recently updated emberjs/ember.js#3329 for an implementation on the above.

Also folks, remember that registerBoundHelper has optional 3-Nth params for dependent keys that'll be observed on the first param of a bound helper invocation that will cause a re-render.

@thomasboyt maybe i'm being a clown but what's the difference b/w

export default { name: "myHelper", fn: myFunction, raw: true }

and

export name "myHelper";
export fn myFunction;
export raw true;

(I'm admittedly not 100% up to date on es6 or what the transpilers are capable so maybe this is silly, but seems to me there's not different between multiple exports and a single default config export)

[thomasboyt]

said in irc, but here for ref too: EAK's resolver only imports the default export of a module. difference is:

export default { name: "myHelper", fn: myFunction, raw: true }
// imported as
import optsHash from "module";

export var name = "myHelper";
export var fn = myFunction;
export var raw = true;
// imported as
import {name, fn, raw} from "module";

eak can only deal w/ the former. resolver is going to need special behavior for dealing with helpers either way, so maybe could be set up to use named exports instead. once es6 transpiler v2 hits you'll be able to use named & default exports together so could even do

export default helperFn;
export var name = "foo";
export var raw = true;
export var dependent = ["foo", "bar", "baz"]

or something

[MeirKriheli]

Been through the discussion, but can't figure out how one's supposed to define the helpers.

Is there some concrete example, which can be integrated with the wiki ?

[hglattergotz]

@MeirKriheli This https://github.com/nihique/fire-up-ember-app-kit is a little bit out of date, but was very helpful for me to get started.
I agree, it would be nice to have this in the wiki.

[mixonic]

I'm also not sure what the current state here is. Fwiw, I would like to share this helper I've used a few times:

// Translated from CoffeeScript and un-tested in the wild, so take care.
function importTo(namespace, directory, suffix){
  var directoryFinder = new RegExp("\/"+directory+"\/");

  Ember.keys(define.registry).filter(function(key){
    return directoryFinder.test(key);
  }).forEach(function(key){
    var imported = requireModule(key);
    var className = key.split("/")[2].classify() + (suffix || '');
    namespace[className] = imported;
  });
}

// Map 'appkit/models/post' to App.Post
importTo(App, "models");

// Map 'appkit/components/button_bar' to App.ButtonBarComponent
importTo(App, "components", "Component");

// Don't worry about where the helpers go, just require them.
importTo({}, 'helpers');

Some of this isn't even necessary anymore due to the rampant containerization of all the things, but it works well as a stop-gap for pre-container objects, or migrating old code that still expects global App.FooView and such (so long as you do not require dependency injection on them).

[eccegordo]

How would you write this exact code in EAK (from the ember guides)?

Ember.Handlebars.helper('highlight', function(value, options) {
  var escaped = Handlebars.Utils.escapeExpression(value);
  return new Handlebars.SafeString('<span class="highlight">' + escaped + '</span>');
});

Also, if it is relevant, trying to use helper inside component template. e.g.

templates/components/my-component.hbs

{{highlight name}}

I get 'Handlebars' is not defined. errors. Not sure what I have to do. Import Handlebars? Anybody have a working example?

[rwjblue]

Most likely the handlebars not defined errors are actually from JSHint.

You can add it to the .jshintrc file (near the top) so that JSHint knows about the 'Handlebars' global.

You could also use 'Ember.Handlebars' (I think).

[eccegordo]

Ahh thank you. Makes sense. Seems this should be included in the standard setup of EAK. Probably also want to add Ember Data if and when that become standard part of EAK.

[stefanpenner]

emberjs/ember.js#3329 will allow ember to resolve some helpers directly.

[stefanpenner]

#3329 was merged.