Bound helpers in 1.13.x / 2.x?

[brian_ally]

I cannot find anything online about bound helpers that’s less than the lifespan of your average hamster. The docs mention “stateful helpers” but it’s frankly not clear from either the text nor the example what that’s about. I don’t see anything about the example that “interacts with the rest of [the] application” nor saves state, although my guess is that what is meant is that the helper (or its compute method) will be called whenever the template is re-rendered,passing in whatever new value, etc. A bound helper, iow.

Is this what I’m looking for? I tried it (extending Ember.Helper and overriding compute method) but no charm.

1. Is my assumption above correct? (in which case i’ve probably done something wrong)
2. How are people dealing with this issue nowadays. (meaning, any time after mid-2014)
3. If I’m wrong about #1, what the heck is a stateful helper?
4. Whatever you do, don’t select your comment and hit that numbered list widget. Type the numbers out and save your sanity.

[jasonmit]

@brian_ally

I don’t see anything about the example that “interacts with the rest of [the] application” nor saves state

Here is a good example of a helper interacting with the rest of the application via injecting a service and observing a property on it: https://github.com/stefanpenner/ember-moment/blob/master/addon/helpers/-base.js

Previously, this wasn’t intuitive to do and required either explicitly passing the attributes into the helper or accessing a private API. As for if you want to store state on the instance of the helper, you’re free to do so.

An example of that:

embersherpa/ember-helpers-array-contains/blob/master/addon/helpers/array-contains.js#L21

[brian_ally]

Thanks @jasonmit. That first example clarifies things, and gives me an idea for getting around my own problem. I’ve figured out a simpler solution for part of it that does not require a helper.

One thing that’s still a bit confusing about that first example is that it does not implement the compute method. Per the docs:

Helpers defined using a class must provide a compute function.

However, it goes on to say:

Additionally, class helpers can call recompute to force a new computation.

Perhaps that’s sufficient. The documentation isn’t clear on that.

What I would still like to do with a helper is this:

<div class="well message {{classlister msg}}>

export default Ember.Helper.helper.extend({
  let item    = params[0];
  let classes = [];

  if (item.get("starred")) classes.push("starred");
  if (item.get("hidden")) classes.push("xhidden");  // avoid conflicts
  if (item.get("self")) classes.push("self");

  return classes.join(" ");
});

Although this first naive approach has a strong whiff of anti-DRY, it nonetheless works fine until a property on msg changes. So, it looks like the solution is to add an observer inside the helper. That was my first thought yesterday but i wanted to make sure i wasn’t missing something that’s already baked into Ember.Helper.