Where should i put Class reopens when something uses them as configuration?

[j-mcnally]

I am running into a problem with ember-simple-auth.

It is unclear when using ES6 modules where to put class reopens.

Basically i have:

Ember.SimpleAuth.Authenticators.Devise.reopen
  serverTokenEndpoint: 'http://localhost:3000/api/v1/tokens'

The only place i can put that and have it work is app.js is there any pattern for this to load this type of stuff via a separate configuration module?

It seems like an initializer would be the right place but theres no documentation on how that would work, for an initializer do i just need a to return a function or an object that would bootstrap this code?

[MajorBreakfast]

Our official docs show how to build an initializer.

Maybe @rjackson has some tips based on how class reopening is handled in es6 ember.

[j-mcnally]

@MajorBreakfast i know this isn't a bug but it would be nice to have a proper way to do this, and docs. Thanks for the reply.

[MajorBreakfast]

Our initializer docs seem fine, here is how it could look like for your case:
(although suggestions are alway welcome!)

// app/initializers/simple-auth.js
export default {
  name: 'simple-auth-configuration',
  initialize: function() {
    Ember.SimpleAuth.Authenticators.Devise.reopen({ // Devise -> Device?
       serverTokenEndpoint: 'http://localhost:3000/api/v1/tokens'
    });
  }
};

No docs on class reopening though. It would be nice to have a pattern. I'm not sure, though, how class reopening fits together with modules. It's not side effect free.

[j-mcnally]

Yeah maybe i wasn't clear sorry about that, i knew how to do the initializer, sorry that wasn't an issue. Your example is exactly what i was thinking, so i think id start with that for now. Thanks a ton!

I agree having a actual prescribed convention / pattern, would be really nice.

[runspired]

I'm struggling looking for the right pattern for class reopens too.

I'm trying to inject my store:main and session:main onto all instances of pusher (a class I've created that adds websocket listeners to update or create records for a given type in the store). Since pusher is not an ember recognized factory, I've been using reopen to accomplish this.

Model specific pushers extend the pusher class to add specific event names and utilize hooks. During object initialization, an assertion in made to ensure that socket and store are present. In the ember-cli/es6 pattern, this assertion fails.

UPDATE: the es6 pattern below does work, I just needed to position my initializer for session to happen after the initializer for store within the ember-cli pattern, I got away with leaving that off before, still looking for thoughts on best pattern.

Global Pattern

/utils/pusher.js
/pushers/foo.js
/initializers/pusher.js
    |_ pusher.reopen({
            store : container.lookup('store:main'),
            socket : container.lookup('socket:main')
        })
/app.js
    |_ready
          App.FooPusher.create();

ES6 Pattern

/initializers/pusher.js

import Pusher from "../utils/pusher";

export default {
    name: "pusher",
    after: "socket",

    initialize: function (container) {
        Pusher.reopen({
            store : container.lookup('store:main'),
            socket : container.lookup('socket:main')
        });
    }
};

/initializers/start-pushers.js

import FooPusher from "../pushers/foo";

export default {
  name : 'start-pushers',
  after : 'pusher',
  initialize: function () {
    FooPusher.create();
  }
};

[stefanpenner]

App.FooPusher.create(); is bypassing injections and the container, I would advise against this.

Pusher.reopen({
            store : container.lookup('store:main'),
            socket : container.lookup('socket:main')
        });

should just be injection rules, which isn't possible because you are bypassing it.

[runspired]

That's what I was doing for the globals based version of the app (which worked) before converting it to ember-cli and es6.