-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
[FEATURE glimmer-custom-component-manager] Custom Component Manager #15254
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
Conversation
| let managerId = layout && layout.meta.managerId; | ||
|
|
||
| if (managerId) { | ||
| customManager = owner.resolveRegistration(`component-manager:${managerId}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in general we want either .lookup or .factoryFor().class instead of resolveRegistration.
packages/ember-glimmer/lib/index.js
Outdated
| export { setupEngineRegistry, setupApplicationRegistry } from './setup-registry'; | ||
| export { DOMChanges, NodeDOMTreeConstruction, DOMTreeConstruction } from './dom'; | ||
| export { registerMacros as _registerMacros, experimentalMacros as _experimentalMacros } from './syntax'; | ||
| export { default as ExperimentalComponentManager } from './syntax/experimental-component-manager'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure we need to export this, I don't think that we want folks extending from our curly component manager. We want to allow them to create their own (which is basically "just" implement XYZ hooks and go to town).
| @@ -0,0 +1,308 @@ | |||
| import { OWNER } from 'ember-utils'; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about this file naming. I'd prefer packages/ember-glimmer/lib/component-managers/curly.js.
| this.owner.register('component-manager:glimmer', new TestComponentManager()); | ||
| this.registerComponent('foo-bar', { | ||
| template: '{{use-component-manager "glimmer"}}hello', | ||
| managerId: 'glimmer' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably shouldn't use glimmer here, because we actually intend to use that managerId in the future and it may confuse future readers of the test about what we are talking...
| @@ -0,0 +1,27 @@ | |||
| import { moduleFor, RenderingTest } from '../utils/test-case'; | |||
| import TestComponentManager from './helpers/test-component-manager'; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to just implement a super simple manager in this file directly, for now we don't have a need for it across many files...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not attempt to extend from the curly manager, but create a new one that satisifies this interface.
|
|
||
| this.render('{{foo-bar}}'); | ||
|
|
||
| this.assertComponentElement(this.firstChild, { content: 'hello' }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These assertions should somehow ensure that the correct manager was used. Perhaps the manager could add a special attribute to the element (for example) that you could assert is present?
| @@ -0,0 +1,26 @@ | |||
| const PRAGMA_TAG = 'use-component-manager'; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this play with ember-cli/ember-cli-htmlbars#114? It seems like only one or the other should be required, not both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would make more sense to leave AST transform here.
| if (options.moduleName) { | ||
| let meta = options.meta; | ||
| meta.moduleName = options.moduleName; | ||
| meta.managerId = options.managerId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This block is only meant as a fallback for older versions of ember-cli-htmlbars which passed { moduleName: 'here' } instead of { meta: { moduleName: 'here' } }. No need to put managerId here like this.
This is the first step towards opening up new APIs for Ember.js community as per [Custom Components RFC](https://github.com/emberjs/rfcs/blob/custom-components/text/0000-custom-components.md). This will allow the following: + add-on authors can now start experimenting with Glimmer API while continue to support existing Ember.js components + developers will be able to _opt into_ using custom component managers This change should be considered cutting-edge and introduced behind a feature flag `GLIMMER_CUSTOM_COMPONENT_MANAGER`. To enable this feature flag in `config/environment.js` of your Ember application: ```js module.exports = function(environment) { let ENV = { ... EmberENV: { FEATURES: { 'glimmer-custom-component-manager': true } } }; ... return ENV; }; ``` Or in Glimmer application, `config/environment.js`: ```js module.exports = function(environment) { let ENV = { ... GlimmerENV: { FEATURES: { 'glimmer-custom-component-manager': true } } }; return ENV; }; ``` After that, you should be able to opt into registering your own component managers: + for applications App with classic structure: ``` my-app/ component-managers/ nyan.js components/ templates/ components/ nyan-cat.hbs ``` ```hbs {{!- tempates/components/nyan-cat.hbs -}} {{use-component-manager "nyan"}} <h1>🐱</h1> ``` App with Module Unification: ``` my-app/ src/ ui/ component-managers/ nyan.js components/ nyan-cat/ template.hbs ``` ```hbs {{!- src/ui/components/nyan-cat.hbs -}} {{use-component-manager "nyan"}} <h1>🐱</h1> ``` + for add-ons ``` nyan-cat-addon/ addon/ component-managers/ glimmer.js app/ templates/ components/ nyan-cat.hbs ```
|
LGTM, we can land once green. Can you comment on the RFC PR mentioning the initial implementation here? |
|
Thanks for working on this @twokul! |
|
@rwjblue sure thing. thanks for reviewing! |
This is the first step towards opening up new APIs for Ember.js community as per
Custom Components RFC.
This will allow the following:
This change should be considered cutting-edge and introduced behind a feature flag
GLIMMER_CUSTOM_COMPONENT_MANAGER.To enable this feature flag in
config/environment.jsof your Ember application:Or in Glimmer application,
config/environment.js:After that, you should be able to opt into registering your own component managers:
App with classic structure:
App with Module Unification: