Ember.js Module LoadingOr, how to almost certainly confuse yourself with limited terminology.
Explaining DI to a 5 year old
When you go and get things out of the refrigerator for yourself, you can
cause problems. You might leave the door open, you might get
something Mommy or Daddy doesn't want you to have. You might even
be looking for something we don't even have or which has expired.
What you should be doing is stating a need, "I need something to drink
with lunch," and then we will make sure you have something when you sit
down to eat.
John Munsch, StackOverflow
Ember’s Module Loader: Terms
● Owner - The object managing this object’s lifecycle
● Container - Manages the lifecycle of instances
● Registry - Stores options, injections, and factories
● Resolver - Resolves a fullName (type:name) to a specifier (filename)
● Module Registry - Fetch a specifier (e.g. from AMD)
Ember’s Module Loader
Server Client
ES Modules
AMD Modules
Ember’s Module Loader
Client
AMD Modules
Container
Registry
Resolver
Registry
ES Modules
Server
Ember’s Module Loader
Client
AMD Modules
Container
Registry
Resolver
Registry
ES Modules
Server
lookup(‘service:notes’)
define(‘my-app/services/notes’, ...)
Ember’s Module Loader
Client
AMD Modules
Container
Registry
Resolver
Registry
ES Modules
ServerFile / Filename
Factory / Module name
Class / Fullname
Ember’s Module Loader: Register a Factory
// app/instance-initializers/storage.js
function storage(appInstance) {
appInstance.register('service:storage', window.localStorage);
}
export default {
name: 'storage',
initialize
}
Ember’s Module Loader: Customize the Resolver
// app/resolver.js
import Resolver from 'ember-resolver';
import Ember from 'ember';
export default Resolver.extend({
resolve(fullName) {
let factory = this._super(...arguments);
if (!factory && fullName.indexOf('service:') === 0) {
return Ember.Service.extend();
}
}
});
Two efforts: Glimmer/di, and Module Unification
● Use Ember-style DI without Ember ● Routable Components● Local Lookup● Addon Namespacing
Things you want to be the same
● Filenames on disk
● Semantics of the DI system
A few things that will improve
Ember’s Module Loader: Too much string manipulation
Client
AMD Modules
Container
Registry
Resolver
Registry
ES Modules
Server
Ember’s Module Loader: Too many lookup failures
appInstance.factoryFor('component:my-input');
app/components/my-input/component
app/components/my-input
Ember’s Module Loader: Too many lookup failures
appInstance.factoryFor('component:my-input');
app/components/my-input/component
app/components/my-input
app/pods/components/my-input/component
app/pods/components/my-input
Ember’s Module Loader: Too many lookup failures
At build time, compiles:
app/components/my-input/component.js with a default export
app/components/my-input.js with a named export
To an "absolute specifier"
component:/app/components/my-input
Ember’s Module Loader: AMD
Client
AMD Modules
Container
Registry
Resolver
Registry
ES Modules
Server
Ember’s Module Loader: Better home for the resolver
Client
AMD Modules
Container
Registry
Resolver
Registry
ES Modules
Server
Container
Registry
Resolver
Registry
More goals
● TypeScript (can pass through types)
● Drop cruft
● More work during build time
The plan
● Integrate Glimmer/di into Ember behind a feature flag, replace its
current DI system
● Permit Ember apps on canary to use Glimmer/resolver to support
Module Unification
● Build a version of the Ember Resolver that supports both classic and
Module Unification lookup
Three Resolvers
● DefaultResolver - Lives in Ember, Globals
● Ember-Resolver - Comes with CLI, supports “classic” and pods
○ We want to add a “migrate” resolver to this
● Glimmer/resolver - Opt-in
Hard bits
● Ensure Ember and Glimmer/di use the same API, or code
● The build system, how can MU do more statically
● Continue to support the current Ember Resolver API
● Continue to support the current Ember CLI Resolver
● Deprecate the globals mode resolver
Ember’s Module Loader
Client
AMD Modules
Container
Registry
Resolver
Registry
ES Modules
Server
ThanksGo shave. @mixonic