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

Cleanup #214

Merged
merged 2 commits into from
Mar 14, 2017
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions text/0000-custom-components.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ Since those proposals, we have rewritten Ember's rendering engine from the groun
up (the "Glimmer 2" project). One of the goals of the Glimmer 2 effort was to
build first-class primitives for our view-layer features in the rendering engine.
As part of the process, we worked to rationalize these features and to re-think
the role of components in Ember.js. This execrise has brought plenty of new ideas
the role of components in Ember.js. This exercise has brought plenty of new ideas
and constraints to the table.

The initial Glimmer 2 integration was completed in [November](http://emberjs.com/blog/2016/11/30/ember-2-10-released.html).
Expand Down Expand Up @@ -330,7 +330,7 @@ class MyManager implements ComponentManager<MyStateBucket> {

instance.setProperties(args.named);

return { secret, instance };
return { immutable, instance };
}

// expose the component instance (but not the internal details) as
Expand Down Expand Up @@ -383,7 +383,7 @@ class PooledManager implements ComponentManager<Object> {
return instance;
}

...
//...

}
```
Expand All @@ -398,7 +398,7 @@ with individual features PAYGO (pay-as-you-go). The Glimmer architecture makes
it possible to break down the work of component invocation into small pieces.

For example, a "template-only component" doesn't need Glimmer to invoke any
the hooks related to lifecycle management of the *component instance*.
of the hooks related to the lifecycle management of the *component instance*.
Therefore, in an ideal world, they should not pay the cost associated with
invoking those hooks.

Expand Down Expand Up @@ -427,7 +427,7 @@ const { capabilities, definition } from Ember.Component;
export default definition({
name: "foo-bar",
capabilities: capabilities("2.13"),
...
//...
});
```

Expand Down Expand Up @@ -474,7 +474,7 @@ export default definition({
someFeature: true,
anotherFeature: true
}),
...
//...
});
```

Expand Down