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

injector hierarchy #13

Closed
WalterLeinert opened this issue Jul 10, 2017 · 5 comments
Closed

injector hierarchy #13

WalterLeinert opened this issue Jul 10, 2017 · 5 comments

Comments

@WalterLeinert
Copy link

Hi Minko,

I'm implementing a framework for efficiently creating modern web apps based on angular (2), express and knex. For the angular part I'm using angular DI, for the express part I'm using ts-express-decorators DI.

For the part which is client/server independent I started to use injection-js because it's compatible with angular and really powerful. Now I'm implementing decorator based modules and components like in angular, but have some trouble with creating the injector hierarchy.
Like in angular I experiment with bootstrapping my root module with a root component and providers.

What is the right way to setup and link hierarchical injectors? When to use ReflectiveInjector.resolveAndCreate()/createChildFromResolved() or something like this?

Is it possible to reset your library (global state) to some initial state for unit testing and testing the bootstrapping in various tests?

Regards,
Walter

@mgechev
Copy link
Owner

mgechev commented Jul 10, 2017

This might be helpful.

Also, take a look at the API of ReflectiveInjector (it looks like you're already familiar with it).

@mgechev mgechev closed this as completed Jul 10, 2017
@WalterLeinert
Copy link
Author

WalterLeinert commented Jul 11, 2017 via email

@mgechev
Copy link
Owner

mgechev commented Jul 11, 2017

I am happy you solved the issue. The @Injectable decorator in the first class declaration in not necessary since you already have another decorator applied.

@WalterLeinert
Copy link
Author

WalterLeinert commented Jul 11, 2017 via email

@mgechev
Copy link
Owner

mgechev commented Jul 11, 2017

It doesn't do anything, since the declaration metadata generation is already triggered by @FlxComponent. You can still keep it for more explicit code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants