We Keep Coding

Node/NestJs: How to inject a class from within a method?

manage-document.service.ts
WorkflowApprovalCallback(){
//subscribing to workflow event
this.makeAnEntryInDb(); // this is undefined
}
makeAnEntryInDb(){ //another function in same class}
workflow.service.ts
someWorkflowMethod(){
event.emit(data);
}
Both are in different classes and different modules. They are in no way related.
The problem is that when workflow service's someWorkflowMethod() is invoked it emits an event.
This is event is being listened to by the manage document service's WorkflowApprovalCallback(). I want to call makeAnEntryInDb() but then we do not have an instance of manage-document so this is undefiend.
If I create a new instance of manage-document class with new keyword I will have to manually create and provide the constructor dependencies. Also it may create multiple instances of manage-document
How can I provide manage-document context or what is the correct way of doing it?
I can not import manage-document service in workflow because there could be a lot of such services that may need to be imported in workflow. I want to keep workflow independent. Not having to make any changes anytime there is a new service.

Dependency Injection Framework - Dependency Propogation

I understand what Dependency Injection is but I still don't see the full picture yet in terms of how it benefits the consumer. See example below.
//bad
class car () {
var tire = new Tire('snow');
}
//good
class car () {
var tire;
constructor(tire){
this.tire=tire
}
}
So most articles I have read state that the above example is good since it eliminates the tire dependency from car and thus becomes more testable. But what about the other class that instantiates a car object. If a driver class was to summon a car class would that not force the driver to instantiate car object and the tires as well. It seems like as though the dependency always gets propagated further up. Where does this end? What actually instantiates objects? Is this what DI frameworks are all about?

You are correct that the dependency requirements get "propagated up" all the way. The driver wanting to instantiate their car needs to bring the Car and the Tires. A driver pool with many drivers would need to bring the Drivers, Cars and Tires and so on and so forth. The simple way to combat that is bundling things into a factory:
class Driver {
constructor(carFactory) {
this.car = carFactory.newCarWithRegularTires();
}
}
(Only for illustrative purposes, see below.)
You can inject a different factory which can create other cars, and the dependency of a Car can change without Driver needing to be aware of any of this.
Taken a step further, you can create a general global factory which can create all kinds of objects and knows how to satisfy the dependencies of each, which is a dependency injection container. You typically configure them in a textual format, declaring that a Car needs a Tire, and when you ask it for an instance of Car it knows to instantiate a Tire first and pass it.
The disadvantage of a DI container is that while you can still swap dependencies simply by reconfiguring the DI container, that sometimes means you have to reconfigure the entire thing and it becomes a giant interdependent object registry. You should avoid creating one giant über-container, but keep things modular.
Another word on factories: the above factory example isn't great. An object should use a factory if it needs to create new instances of objects at runtime. It should not use a factory simply to satisfy a dependency that could be injected directly.
In the end you want to strike a balance between classes declaring and receiving their dependencies directly, but also not creating extremely deep dependency hierarchies. Keeping dependencies as shallow as possible is a good start, introducing factories or modular DI containers at stategic points is another way.

Should I use a single Model object for the whole SPA or many small models for each component?

I am thinking about how to organize Model in my webapp. I have two options, as I see it:
Create a single globally available Model object, then on instantiating new components they must register themselves in the Model object via methods, then update it when their state changes. Others would listen to changes from the Model by some key.
Create a model object for each component and let others know via some Event dispatcher about their state change.
In 1st case I feel like it will be easier to manage all the state change in one place, have more standardized way of doing it, while with the latter scenario I think it will be harder to maintain consistence over the system.
What are the factors I should base the decision on?

I would go with the first but adding the idea of the second: Instead of the components checking constantly the keys for changes you can make the only model signal the components when needed after they register. You can pass the signal/callback with the register itself.
That way you don't need to create an army of models that update themselves (that might also mean you have to avoid cyclic propagation). In addition to this, if I understand correctly it would violate the single source of truth. Also it looks worse both memory and performance wise.

Should Flight.js component instances make use of shared variables?

I am just getting started with Flight.js and realized that component instances share local variables, but didn't find anything about it in the documentation.
This is what i mean:
flight.component(function () {
var sharedBetweenAllInstances = true;
this.notShared = true;
}).attachTo('.multiple-elements');
As example, if a component should count clicks on it, it could increment this.clicksCount for the number of clicks on each single instance, and increment var totalClicks for the total number of clicks on any instance of the component.
I didn't find anything about this in the documentation, so I wonder if flight components should be used this way?
Thank you!

I don't think that's a good idea (probably why they don't mention it in the docs). The function you setup as your "component" is actually applied as a functional mixin, along with any other mixins your component uses. So, while you might be able to access that variable when doing an .attachTo('.multip-selector') where you're setting up an instance on each of many components, you could still run into problem if attaching individually, or if the shared variable controls resources in which a race condition to access that shared resource becomes problematic.
From a "component" standpoint, you're better off pulling out any shared state into a separate data component or controller type component that can receive updates form the individual components and broadcast the shared state when it's updated.
Here's an example I put together using that scenario via jsbin: http://jsbin.com/qecupi/edit?js

Where would you instantiate nested components using Closure Library?

Closure library offers a basic life cycle for Components:
Instantiation
Rendering/Decoration
Document Entering
Document Exiting
Disposal
I'm focusing on the first two. About design patterns, when is it better to instantiate a nested component in the first steps?
Instantiation: needs to be hold on a property till added through addChild and consumes memory before necessary. Anyways, it allows to do some dependency injection or better initialization because of the parameters it receives.
Rendering/Decorating: messes up the dom creation, which can be already complicated because of the references of other objects it needs. It also would need the instantiation parameters previously stored in some property. Anyways, holds the instantiation till is needed.
Maybe a separated method called after instantiation which wraps the rendering? I'm asking because Closure Libray book and documentation don't talk about this.

Doing some refactorying and trying to split logic, came to the following conclusion:
The best option I've found so far is to create the components inside the createDom method:
Normally, the parameters needed for components involve the data they present. My arquitecture uses DAO, which means all data objects are conveniently connected. Subcomponents usually need some other data objects which are accessible by the parent's DAO. Since the parent object is needing this DAO, it's ok to store it on a property for the use inside the createDom.
The other thing is that instantiation and rendering in the createDom component, theoretically, only needs two lines, which isn't a mess.
Again, it's the best possible solution to increase cohesion.