Hi guys,
I’d like to count with your wisdom here.
I tried to condensate as much as possible my screenshot and question.
I’d like to understand the Dependency Injection behavior. If I use Container.instance.get(Store) in my canActivate method, and than I try to use it the bind method, the instances are not the same, in the Bind method I don’t have my initialState and actions anymore.
My problem was way bigger than that, but I could solve it saving an instance of the Store somewhere in my application.
Am I doing somethign wrong?
1 Like
just a question.
why you don’t use DI in the constructor and save the instance as a class variable to be used later in canActivate and bind? [using autoinject, and not by accessing the Container directly]
this is the correct way to use DI.
regardless - it should work your way too: maybe you registered the store as transient?
1 Like
A common issue is trying to DI request the Store before the plugin did the registration aka in main.ts
1 Like
According to the docs you should get the same singleton instance by default so I believe your thinking is correct. It may be something peculiar with the Store, assuming you have the standard initialState setup.
Do you get the same result with other lifecycle stages, e.g. activate, attached instead of bind, or doing the first get at a later stage, i.e. later than canActivate?
I’d test it myself but I’m sadly without a PC at the moment.
That “saving an instance” works would suggest that the container is losing the reference somewhere, which, as @avrahamcool mentioned, would indicate that the Store might be transient or that your DI container is getting disposed somewhere between the lifecycle stages and might be picking up your stored instance somehow.
How are you setting up the Store plugin and what’s your VM class configuration, i.e. does it have the @transientdecorator, use determineActivationStrategy() (which can also be accomplished via the route config), etc.?
1 Like
Hei guys, thanks to you I fond the problem, I was trying to check your suggestions about the lifecycle and transient, when I found out there was a const container = new Container().makeGlobal(); beeing made in the middle of a file, not a class, something weird, somebody left it there.
I didn’t understand excactly why, but it changes the Container.instance = this; in the aurelia-dependency-injection.js file.
We use .makeGlobal() it in the Unit Tests, as a suggestion made by someone here in the channel in the past.
Well, I’m sorry I bothered you guys, but this made me go and check further in the code and finally discover the real problem.
Thank you!
1 Like
MakeGlobal is primarily used in unit tests where you want to create a fresh new root container. Glad you found the issue
2 Likes
