Modifier managers

[chadhietala]

Rendered

[dfreeman]

This might be a better question for @mixonic over in #367 (since setComponentManager already exists and likely faces the same question), but given that this API is primarily expected to be consumed from addons, how does this work with MU/explicit packages?

Would it be something like setModifierManager('super-cool', { package: 'super-cool-modifiers' }, EmberObject.extend(...))?

[rwjblue]

Yes, I think your suggestion makes sense, but would you mind chiming in over in #367?

[mixonic]

This seems reasonable to me, if mildly annoying for authors. Given that this is a low-level API the annoyance is probably permissible.

I think the most direct way forward is to update this RFC to include both MU and non-MU examples for how to use the setModifierManager API. This will help focus the number of cases and solutions, which are really not that many.

[nightire]

component managers -> modifier managers

[acorncom]

Should this be 3.6 instead of 3.2? Seems to fit better with the rest of the hypotheticals below ...

[ryanto]

Might be a dumb q, but how does this relate to the Modifiers RFC?

Is the idea here that this happens first? Experiment with a modifier APIs through various managers + capabilities?

[sandstrom]

I vote for the alternative suggested at the end of this RFC:

Instead of exposing low-level primitives we should ship the high level API as described in RFC#353

I understand the thinking behind exposing primitives — and I like that. But I'd say that the original modifiers RFC #353 already do expose primitives. This RFC is taking it a bit too far, by exposing ’primitives behind the primitives‘.

Also, there are always resource constraints and for everything you decide to do, there is one thing that you're not doing. The idea presented here isn't inherently bad, but I'd like to question whether it's on the top 10 list of things that the Ember community want to prioritize. In my opinion #353 already give us 90% of the tools we need, and we should simply ignore the remaining 10% (this RFC) and focus on other things in Ember land.

All that said, I want to point out that I have a lot of respect for your contributions to Ember @chadhietala 🏅, and I really like and support the original RFC (#353).

---

As an aside I'd like to mention that the capabilities concept is clever and if this RFC ends up being shelved the capabilities concept may be useful for other things related to addons.

[mixonic]

@ryanto Yes, this RFC is suggested as the first implementation path for modifiers in Ember. It would allow us to implement whatever high-level helpers we want for the framework as addons, and skip over the challenge of an app-developer-friendly design for authoring modifiers. As is evinced in #353 there are some tricky things to design for an app-developer-friendly design, such as the interaction with FastBoot and how much of a similar-to-current-components-vs-future-glimmer-components tradeoff to make.

[chadhietala]

I have updated the RFC to show how we will associate the manager and the base class. The TL;DR is to pass the import binding.

// my-app/app/modifier/foo.js

import EmberObject from '@ember/object';
import Basic from './basic-manager';
import { setModifierManager } from '@ember/modifier';

export default setModifierManager(Basic, EmberObject.extend({
  // ...
}));

There should be a similar RFC for setComponentManager.

[chadhietala]

After the core team call today we decided that a better API would be to pass a function that receives an Owner and returns an instance of the custom manager. This design allows for some indirection (if needed) and general speaking allows us to code against the interface instead of the concretion.

import EmberObject from '@ember/object';
import { createManager } from './basic-manager';
import { setModifierManager } from '@ember/modifier';

export default setModifierManager(createManager, EmberObject.extend({
  // ...
}));

// my-app/app/modifier/basic-manager.js

// ...

export function createManager(owner) {
  return new BasicManager(owner);
}

[rwjblue]

After reviewing this at the core team meeting yesterday, we are in favor of this moving into the final comment period.

[rwjblue]

Lets do this!