Use glimmer-di or similar for Container #284
Milestone
Comments
|
So using glimmer-di is blocked on their support for a Unless a good use case can be made for Glimmer / Ember to use We should investigate whether this is feasible, and if so, make the case in the issue linked above. We could then fork glimmer-di for now, adding |
davewasmer
added a commit
that referenced
this issue
Mar 20, 2017
The resolver and related refactor enables: 1. Lazy loading of app code, which is now the default. It doesn't preclude eager loading though, and future work could add an eager load option for production environments. 2. Customizable directory structures. This is generally not a good idea for the casual use case, but it's possible that some additional type of code asset might need different lookup rules (i.e. test files) 3. Cleaner addon / application loading. The application logger is now customizable by simply adding `app/logger.js` (as long as the interface matches). Same for the `app/router.js`. This also solves some outstanding issues: fixes #285, #284
This was referenced Mar 20, 2017
Merged
davewasmer
added a commit
that referenced
this issue
Mar 21, 2017
The resolver and related refactor enables: 1. Lazy loading of app code, which is now the default. It doesn't preclude eager loading though, and future work could add an eager load option for production environments. 2. Customizable directory structures. This is generally not a good idea for the casual use case, but it's possible that some additional type of code asset might need different lookup rules (i.e. test files) 3. Cleaner addon / application loading. The application logger is now customizable by simply adding `app/logger.js` (as long as the interface matches). Same for the `app/router.js`. This also solves some outstanding issues: fixes #285, #284
davewasmer
added a commit
that referenced
this issue
Mar 25, 2017
The resolver and related refactor enables: 1. Lazy loading of app code, which is now the default. It doesn't preclude eager loading though, and future work could add an eager load option for production environments. 2. Customizable directory structures. This is generally not a good idea for the casual use case, but it's possible that some additional type of code asset might need different lookup rules (i.e. test files) 3. Cleaner addon / application loading. The application logger is now customizable by simply adding `app/logger.js` (as long as the interface matches). Same for the `app/router.js`. This also solves some outstanding issues: fixes #285, #284
davewasmer
added a commit
that referenced
this issue
Mar 25, 2017
The resolver and related refactor enables: 1. Lazy loading of app code, which is now the default. It doesn't preclude eager loading though, and future work could add an eager load option for production environments. 2. Customizable directory structures. This is generally not a good idea for the casual use case, but it's possible that some additional type of code asset might need different lookup rules (i.e. test files) 3. Cleaner addon / application loading. The application logger is now customizable by simply adding `app/logger.js` (as long as the interface matches). Same for the `app/router.js`. This also solves some outstanding issues: fixes #285, #284
davewasmer
added a commit
that referenced
this issue
May 1, 2017
The resolver and related refactor enables: 1. Lazy loading of app code, which is now the default. It doesn't preclude eager loading though, and future work could add an eager load option for production environments. 2. Customizable directory structures. This is generally not a good idea for the casual use case, but it's possible that some additional type of code asset might need different lookup rules (i.e. test files) 3. Cleaner addon / application loading. The application logger is now customizable by simply adding `app/logger.js` (as long as the interface matches). Same for the `app/router.js`. This also solves some outstanding issues: fixes #285, #284
davewasmer
added a commit
that referenced
this issue
May 1, 2017
The resolver and related refactor enables: 1. Lazy loading of app code, which is now the default. It doesn't preclude eager loading though, and future work could add an eager load option for production environments. 2. Customizable directory structures. This is generally not a good idea for the casual use case, but it's possible that some additional type of code asset might need different lookup rules (i.e. test files) 3. Cleaner addon / application loading. The application logger is now customizable by simply adding `app/logger.js` (as long as the interface matches). Same for the `app/router.js`. This also solves some outstanding issues: fixes #285, #284
|
Fixed in #288 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, the Container class poorly encapsulates it's responsibilities.
glimmer-di provides a nice set of abstractions for various responsibilities - a Resolver responsible for mapping lookups to filesystem (right now handled by the Application class in Denali), a Registry for manual registrations (handled by Denali's Container class), a Container for instantiation, etc.
The text was updated successfully, but these errors were encountered: