Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Injection Parameter Normalization #451

Open
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@pzuraq
Copy link
Contributor

pzuraq commented Feb 20, 2019

Rendered

pzuraq added some commits Feb 20, 2019

@rwjblue rwjblue self-assigned this Feb 20, 2019

@rwjblue rwjblue added the T-framework label Feb 20, 2019

@Gaurav0

This comment has been minimized.

Copy link
Contributor

Gaurav0 commented Feb 21, 2019

Oh jeez. The Ember 3.6 update was already painful for me, and we weren't using as many native classes as we are now.

Also, I actually think this makes things more complicated than they are now. Right now, if it extends Ember.Object, use init, otherwise use constructor. I think this RFC makes it more complex deciding which to use.

I know this is supposed to make things easier to teach for new users, but I don't think it will, Most new users will still have to deal with classic components and utility classes for some time because they maintain code at companies or they use Ember addons.

@jessica-jordan jessica-jordan referenced this pull request Feb 21, 2019

Merged

Ember Times No. 86 - February 22nd, 2019 #3821

11 of 20 tasks complete
@pzuraq

This comment has been minimized.

Copy link
Contributor Author

pzuraq commented Feb 21, 2019

Right, that’s why we’re planning on having a strong lint workflow that helps users know which one they should use for every class until it has been upgraded.

The workflow is becoming more and more necessary as we go along. For instance, when a user jumps into a component file, are they looking at an classic component or glimmer component? You could look at the import path, but what if the import is for a base class that you’re extending? It’s a lot of work either way, and will be frustrating unless we can catch it early with a linter.

FWIW, the changes proposed are also fully backwards compatible, unlike the changes in 3.6. I am very sorry about those, and about the extra churn 😔 but I do believe this move sets us up for success. If you want, you can keep using the init hook until all other classes have been converted from EmberObject, and then universally switch to constructor.

@amyrlam amyrlam referenced this pull request Feb 22, 2019

Merged

Ember Times No. 87 - March 1, 2019 #3837

12 of 15 tasks complete
@tomdale

This comment has been minimized.

Copy link
Member

tomdale commented Mar 8, 2019

We discussed this at the core team meeting today and, given that the conversation has stabilized, we agreed to move this RFC to Final Comment Period.

@krisselden

This comment has been minimized.

Copy link
Member

krisselden commented Mar 8, 2019

I believe if we made the container system have decorators, same with component manager, we could move off of the base class with minimal effort in the container.

// DI container
const Ctor = lookup(desc);
const obj = Reflect.construct(Ctor);
setOwner(obj, owner);
placeInContainer(obj, desc);
Object.assign(obj, propInjections);
invokeStartIfNeeded(obj);
return obj;

No base class

import { start, teardown } from "@ember/container";
import { tracked } from "@glimmer/tracked"
import { glimmer } from "@glimmer/component"

export default class ClockService {
  time = Date.now();
  #interval = undefined;

  @start
  start() {
    #interval = setInterval(() => this.time = Date.now(), 1000)
  }

  @tracked time;

  @teardown
  destroy() { 
    clearInterval(#interval);
  }
}

export default @glimmer class MyComponent {
  @service clock;

  get time() {
    return this.clock.time;
  }
}
@rtablada

This comment has been minimized.

Copy link

rtablada commented Mar 13, 2019

@krisselden I like the idea of future lifecycles being decorated instead of inherit to the base class (and possibly remove the need for an Ember base class in many cases)

@rwjblue

This comment has been minimized.

Copy link
Member

rwjblue commented Mar 13, 2019

@krisselden - I can't tell if that is a counter proposal, or supporting this RFC by saying we can move away from this in the future by way of decorators. Can you clarify?

@krisselden

This comment has been minimized.

Copy link
Member

krisselden commented Mar 14, 2019

@rwjblue I disagree with the idea that having a new Service base class that receives and just does setOwner(this, owner) is the future to migrate people to. So, yes, I'm objecting.

@rwjblue

This comment has been minimized.

Copy link
Member

rwjblue commented Mar 14, 2019

@krisselden - Gotcha, thank you for clarifying!

@pzuraq pzuraq changed the title Classic Class Owner Tunnel Injection Parameter Normalization Mar 15, 2019

@pzuraq

This comment has been minimized.

Copy link
Contributor Author

pzuraq commented Mar 15, 2019

I've opened up #467 as a potential alternative to this RFC, following discussions with @krisselden about his concerns. I believe either of these RFCs is better than the status quo, but I would probably agree with Kris that normalizing injection hooks is the better path for the future, even if it means changing the Glimmer component API.

@chancancode

This comment has been minimized.

Copy link
Member

chancancode commented Mar 15, 2019

Based on the objection raised by @krisselden, I'm taking this RFC out of FCP pending further discussions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.