[Glimmer] helper no longer receiving `env`

[rlivsey]

In ember-can we've got a helper which expects to receive env but since Glimmer merged it no longer is.

The is defined as so:

export default function(properties, hash, options, env) {
  var abilityName  = properties[0];
  var resource     = properties[1];
  var view         = env.data.view;
  var container    = view.container;

and is then exported as a plain function:

import canHelper from 'ember-can/helpers/can';
export default canHelper;

This may well be an issue in the addon and shouldn't have received env previously, but before I fix it in the addon itself I thought it worth checking if this is a regression or if there's a different way we should be doing this.

[rlivsey]

Just realised I missed a part out, we're manually registering the helper (because it's not hyphenated) in an initializer:

import Ember from 'ember';

import helper from '../helpers/can';

export default {
  name: 'setup-ember-can-helpers',
  initialize: function() {
    Ember.HTMLBars._registerHelper('can', helper);
  }
};

This is using the private _regsterHelper, so I imagine there is no regression here as it wasn't public API.

[rwjblue]

This is using the private _regsterHelper, so I imagine there is no regression here as it wasn't public API.

Yes, it is unfortunate but true. I am sorry 😞

[rlivsey]

@rwjblue is there a different way we should be getting env or the container here?

[wycats]

@rlivsey helpers aren't going to have access to the ambient environment anymore (making sure they reliably update is extremely finicky), but I have some thoughts on how to make a helper like ember-can possible.

There are a few different options, and we can pick a good one once we see a bigger set of the private-API "regressions" that Glimmer caused.

[rlivsey]

@wycats for now I've updated ember-can to use an if-can/unless-can component which covers 99% of use-cases for now.

It means you can no longer compose with liquid-fire (liquid-if (can "foo")) or use it to easily change classes (class="{{if (can "bar") "some-class"}}") but those are pretty rare anyway.

ember-intl is another addon in which I've run into this issue, they rely on env in the helper to get container to lookup the locales & translations service.

[knownasilya]

Both sound like legitimate use cases for accessing env/container. I use ember-can and would love to keep the liquid-if (can "foo") syntax.

[amk221]

+1 I also need to lookup localisation data

[rwjblue]

Just wanted to mention ember-cli-i18n is also in the mix here. See https://github.com/dockyard/ember-cli-i18n/issues/106.

[amk221]

Could somebody mention the potential ideas for accessing the container from a helper? I'm pretty much stuck until I can figure this out.. and I don't want to set off on the wrong foot. Thanks!

[rlivsey]

@amk221 it's essentially 'impossible' right now (where by impossible I mean you can technically do it through a few nefarious means, but they're not a good idea) so AFAICT it's a case of the core team gathering use-cases and seeing what the best public API is to suit these needs.

[cibernox]

Is there any way to track or help with the issue of exposing the container?

There is several extremely popular addons that cannot be updated to work with glimmer without an idiomatic way of using the container.

A good example is ember-cli-i18n, that probably is preventing a few thousands of devs with multilingual apps of trying glimmer.

[mixonic]

@cibernox I'm very aware of the pain. I'll make it my mission today to put together a draft of a proposal for Expression we've kicked around in chat. I'm 100% sure it is the solution for all ills, but I am optimistic.