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.
Related
I am in the middle of building a game using Phaser.js (version 3.20.1) and I want to have this singleton class called TimeTracker which would keep track of the players time as certain event occur throughout the game. So that any scene can call
TimeTracker.AddTime(3)
But my TimeTracker also needs access to a UI screen to display UI messages. Now with other objects what I have done is initialize the UI scene in the Game Controller create method
this.UI = this.scene.get('UI');
and then pass it into the constructor of other objects
this.tableD = new D(this.UI, this.Attributes);
this.tableF = new F(this.UI, this.Attributes);
But since TimeTracker is a singleton how do I write the following pseudo code?
import TimeTracker from '../gameObjects/TimeTracker'(this.UI);
Since UI doesn't exist yet.
Furthermore, as I type this, I wonder if I should go with the singleton approach or just create one instance in create and pass that around also like the UIScene
Is there a best programming practice when sharing one instance of a class across many classes (Scenes in Phaser)?
I have a master application that accepts plugin modules, except for some functionality (authentication) where for some reason it seems hell-bent to prevent plugins from adding authentication methods. Despite that, I still need to do exactly that - add a new authentication method, but via a plugin.
The master application has a typescript module that exports an Authenticator class,
export class Authenticator {
constructor(arg) { dostuff(arg); }
}
I need to somehow intercept the constructor argument and store it in my plugin. The Authenticator class is instantiated in private code, but fortunately, after my plugin is initialized - so I get a chance to run some code; is there any way to dynamically modify the Authenticator class object (i.e. the class itself) so that I may capture the argument, when it is actually instantiated? Note that I can't use a decorator (I'd need to modify the main app), and I can't instantiate a proxy instead of the Authenticator (again, I would need to modify the main app in order to do so).
I've tried modifying Authenticator.constructor or Authenticator.prototype.constructor but neither works apparently. Is there any other way?
I study angular, sorry for the stupid question.
I need to make a service for windows with a single instance of the service or be able to send broadcast events and listen to them in each component.
Using #input and #output is not like There is a different nesting of components.
How to solve this issue?
One way to implement this is to use a service for that.
Inside the service create an Subject member variable (you need RxJS for it, which angular already installed because it's a dependency).
The Subject can be subscribed by any component outside the service (you'll need to inject the service in the component constructor).
Then, whenever you want to trigger that event you call .next() on the Subject and each subscriber will activate its own callback.
When subscription is done and not needed anymore it's important to .unsubscribe() from the Subject, otherwise there's a risk of memory leak (since the subscriber does not unsubscribe itself).
There are many examples out there, here is simple one.
I have a hot RxJS Observable that I want to respond to in different ways depending on the context of the application. The Subject emits a new event based on some global action intercepted by a directive, but then I want
If a child component is subscribing to the Subject, then the child should handle the event
Otherwise, use a global handler
I can get the number of subscribers from the Subject and then tell the global handler to ignore if there are multiple subscribers, but it's not part of the API, so it seems like it may not be the right way to handle it. So what is the right way to do this?
Also, should the global event handler be part of the directive, the service, or should that be in a new component?
You can put global event subject in a global app.service and inject it in other component for subscription.
Although the ideal component should just have its own service maybe to handle complex event, but sometimes I feel directly inject a global service keeps the code cleaner. Otherwise, if you really want complete isolation or the component should be widely reusable e.g UI dropdown list, I suggest to use #Output to fire events (btw angular EventEmitter inherit Subject) and #Input to take in variables.
From what I understand, using the mediator pattern looks something like:
Modules only publish, but don't subscribe. The mediator subscribes to events and makes other modules do things based on those events.
For example, let's say we have a javascript editor. Let's say there's an editor (for the code) and a run tab (where you can click run and see the output of the code). Each of these is its own module. When the user clicks run, the run tab module outputs an event like "runButtonClicked", the mediator subscribes to this event and runs the code when that event is triggered. This example is a little contrived and simplified, but hopefully this gives some idea of what I'm trying to achieve.
So let's say you have some "class", Mediator, that each module communicates with through Pub/Sub.
If I'm understanding this pattern correctly, then this all makes sense. But a problem seems to arise when you want to have multiple instances of this core "application" on the page -- how does the app know which events to respond to and which should be left for the other instances on the page?
It seems like I'd want multiple mediators, but I'm not sure how these would be passed into the objects.
var mediator = new Mediator();
var moduleOne = new moduleOne(mediator);
var moduleTwo = new moduleTwo(mediator);
This method seems problematic because I want access to those two modules inside of the mediator.
I've also heard of the sandbox/facade patterns being used with the mediator, but I'm not sure if either of those would help (that is, I don't understand them very well).
Update
I just found Mediator pattern and creation, which seems like a possible solution. But I'd also like to know if I'm using and thinking about these patterns correctly.
Each instance of the application will need its own event space (or channel) so its events do not pollute the other instances. If the application instances need to talk to one another, then that may require a further event space. Depending on the eventing library you use, there are several ways to do this:
jQuery events support namespaces, so if each application instance has a unique name, you can use the application name as a namespaces to segregate events.
The EventEmitter library supports the creation of multiple EventEmitter instances, unlike jQuery where the events are managed by the jQuery singleton. In this case, you can attach to each application its own EventEmitter instance.
You can also roll your own using the mediator pattern if your library does not have good mechanisms for creating event spaces. In this case, you can create one mediator for each namespace.
The Mediator pattern can be used in conjunction with options 1 & 2, and the list above is by no means exhaustive.
This method seems problematic because I want access to those two modules inside of the mediator.
In order to connect the mediator with the modules it manages, I think you need a separate method to do that. Perhaps something like
var mediator = new Mediator();
var moduleOne = new moduleOne;
var moduleTwo = new moduleTwo;
moduleOne.mediator = mediator;
mediator.register(moduleOne);
moduleTwo.mediator = mediator;
mediator.register(moduleTwo);