I have 2 controllers where I'd like to share data in between. One controller supports a view with a table that often changes it's "selected item" and the other fetches data from an API using said item information. Since those two controllers support views and are on the same page, they don't have a classic parent/child hierarchy, but are more 'siblings'.
Currently, I'm using a simple 'event bus' service which calls an event on the root scope using $emit which I inject in both controllers, where as one listens for changes using $rootScope.$on. Now I heard many times that this is a bad solution and I should use services to share data, but no one really explains how it's possible to watch the data for changes when also
using $watch is bad
$broadcast is bad
(there seems to be really a war on SO on which solution should more be avoided).
My current solution:
Controller1
export class Controller1 {
private eventBus : Components.IEventBusService;
constructor(eventBus: Components.IEventBusService) {
this.eventBus = eventBus;
}
void itemSelected(item : IItemModel) {
this.eventBus.emit("itemSelected", { "item" : item });
}
}
Controller 2
export class Controller2 {
constructor($scope : ng.IScope,
eventBus : Components.IEventBusService) {
eventBus.on("itemSelected", (event, data) =>
this.onItemSelected(data), $scope);
}
private onItemSelected(data: any) {
// do something with data.item!
}
}
EventBusService
export interface IEventBusService {
on(event, callback, scope): void;
emit(event, data): void;
}
class EventBusService implements IEventBusService {
private rootScope: ng.IRootScopeService;
constructor($rootScope: ng.IRootScopeService) {
this.rootScope = $rootScope;
}
on(event, callback, scope) : void {
var unbind = this.rootScope.$on(event, callback);
if(scope) {
scope.$on("$destroy", unbind);
}
}
emit(event, data) : void {
data = data || {};
this.rootScope.$emit(event, data);
}
}
Are there any major drawbacks using this solution? Is 'the service way' better regarding to updating data etc?
You are correct, the $on and $emit should be avoided, as they create unnecessary noise. There's actually a pretty simple solution to this situation, I use it quite a bit.
What you need to have is an object in your service and give one controller a reference to it, and the other that needs to trigger an action can watch the service variable (good job on the TypeScript by the way):
class ItemSelectionWrapper { //just a wrapper, you could have other variables in here if you want
itemSelected: IItemModel;
}
class EventBusService implements IEventBusService {
private myObj: ItemSelectionWrapper;
...
}
Then in your controller that has itemSelected in its scope (let's assume Controller 1) you refer to the same variable:
export class Controller1 {
private eventBus : Components.IEventBusService;
constructor(eventBus: Components.IEventBusService) {
this.eventBus = eventBus;
this.eventBus.myObj = this.eventBus.myObj || {};
this.eventBus.myObj.itemSelected = $scope.itemSelected;
}
}
Now, since in Controller 2 you'll have the service injected, you'll watch the Service's variable:
$scope.$watch(function(){
return busService.myObj,itemSelected;
}, function (newValue) {
//do what you need
});
Is 'the service way' better regarding to updating data etc?
Yes. Reason is that events are like "throw a ball in the air and hope someone catches it". Whereas service is a defined contract on how two controllers would interact.
If you use TypeScript you clearly care about Type Safety, services can give you that.
FYI We have the following guidance internally:
Shared Information between controllers
When a screen is highly nested with various placeholders with their own "html + controller" we need a way to share information (single source of truth) between these controllers.
1 RootController
The main controller for the section. Responsible for exposing the SharedClass instance on the scope (allows nested html segments to have direct access to this model) and any top level controller functions.
2 SharedClass
An angular service as it is easily inject-able into individual controllers / directives. Contains the information / functions that are shared in various portions of the screen e.g. multi select mode, Displayed / selected objects, operations for mutating these objects etc.
3 Individual Html + Controller
These subControllers can request the SharedClass using simple Angular Dependency Injection. The Controller HTML should automatically get access to the SharedClass instance (as that is exposed to scope by RootController).
Related
I have a service to handle some data-fetching and I am trying to use tsyringe with it, the function to create the service gets called multiple times (i cant really do anything about that), so it is creating many instances of the service. I tried to wrap it in "container.isRegistered" checks, but when I do that it doesn't register the service at all.
What I have so far is:
#singleton()
#injectable()
export class Service implements IService {
constructor(#inject('arg1') arg1: string, #inject('arg2') arg2: string) {
}
Then I am registering it here in another file:
if (!container.isRegistered('arg1', true)) {
container.register('arg1', {useValue: this.arg1});
}
if (!container.isRegistered('arg2', true)) {
container.register('arg2', {useValue: this.arg2});
}
if (!container.isRegistered('IService', true)) {
container.register('IService', {useClass: Service});
}
In another file I resolve it like so:
this.service = container.resolve('IService');
Trying to check if it is registered stops the Service from being registered at all, but if I don't I have multiple instances running. The service mainly handles data-fetching, it's only supposed to fetch some data once on startup but I am seeing many calls that do so. I put some logs in the service constructor and I can see it being created many times.
Thanks for your help!
When you are creating new registry in IoC using method register, in fact you create another link on service that doesn't related to your decorator #singlton inside of class. You need set additional parameter in the register method. It will describe lifecycle of injectable object. Because be default it doesn't use Singleton. You should do this like that:
import { container, autoInjectable, Lifecycle } from 'tsyringe';
...
container.register<UsersService>('IService', {useClass: UsersService}, { lifecycle: Lifecycle.Singleton } );
More info here and types here
I have a service and I have 2 solutions from this kind of problem and I want to know what is best and when to use the Subject solution above the Service solution.
I have a UserModel that all my components see with my service, the approach that I want is when I change the UserModel from service, changes it for all my application
1 FIRST SERVICE
export class UserService {
private userModel: UserModel = new UserModel();
public userSubject$ = new Subject<any>();
private timeOut = 20000;
private mainConfig: MainConfig;
constructor(private http: HttpClient) {
this.mainConfig = new MainConfig();
}
getUserModel() {
return this.userModel;
}
setUserModel(user) {
this.userModel = user
}
}
And is just to make this call in my HTML from all my components and will work
this.userService.getUserModel().name
The second approach
2 SECOND SERVICE
#Injectable()
export class UserService {
private userModel: UserModel = new UserModel();
public userSubject$ = new Subject<any>();
private timeOut = 20000;
private mainConfig: MainConfig;
constructor(private http: HttpClient) {
this.mainConfig = new MainConfig();
}
getUserModel() {
return this.userModel;
}
setUserModel(user) {
this.userSubject$.next(this.userModel = user);
}
}
And in my HTML file, I just use
{{ userModel.name }}
And I must make this new line on my example-component.ts
ngOnInit
this.subTemp = this.userService.userSubject$.subscribe(
user => this.userModel = user
);
ngOnDestroy
this.subTemp.unsubscribed();
What is the advantage to make the Subject from direct from Service? Because I need to make much more work
If I could paraphrase your question(s), I'm guessing it'd go something like:
Why should I use Angular Services instead of just making async/http calls directly from the component?/Why should I write Service logic in a separate file as a dependency?
and
Why should I use lifecycle methods like ngOnInit and ngOnDestroy in conjunction with Services or async/http calls?
When it comes to questions like these, the Angular framework is more opinionated than other SPA technologies like React, Vue, etc. So while you're not technically forced to follow either of the approaches you listed, you should know of the downsides and problems that emerge if you follow the first approach rather than the traditional injectable Service approach(number 2).
Generally speaking, the Angular team recommends following a unidirectional data flow pattern in your app implemented with Services. This means that data flow should generally come from Services which distribute the data to components and then to view templates.
Within this pattern, there's also an implication of separation of concerns which is a good practice to follow within any app. Services should handle fetching and handling data, components should handle view logic, and templates should be as clean and declarative as possible. Components and their templates should consume data that's been processed already. Relatedly, you should try to keep your components as pure as possible - meaning they produce as few side effects as possible. This is because components are dynamically mounted and unmounted in the course of a user session. Have a look at this article for more information on pure components.
Aside from the above architectural discussion of Services there are some other, more concrete consequences to be aware of:
Failure to unsubscribe from observables can lead to memory leaks in your application. With the first scenario you've outlined above, a component may be loaded 10-20 times in a user session and each time you're setting up a new subscription without tearing it down again. This can have a very real performance impact on your app.
The Angular compiler is optimized to add and remove dependencies dynamically, resulting in better app performance. If you keep all your Service code right in your component, they'll be larger and slower. From a UX perspective, components should be as light and nimble as possible so they can load quickly for the user.
If you register a service as a provider, the Angular compiler will treat it as a singleton meaning there can be only one instance of it. This is as opposed to the many instances of a Service class generated with each component if you were to use the first approach you listed. This is another performance benefit of using injectable Services.
The Angular compiler is optimized to work with the DI framework so your next step may be to learn more about it and the implications of going with one approach or the other. There's a long talk about creating your own Angular Compiler that's a couple years old now that might be helpful.
What you wish to know is the difference between pull based method vs push based method of retrieving data.
Method 1: pull based
As the name suggests the pull based method is traditional method where you for eg. call a function and it returns the value once. If you need the value again, the function should be called again. And you exactly when the data will arrive.
export class UserService {
private userModel: UserModel = new UserModel();
getUserModel() {
return this.userModel;
}
setUserModel(user) {
this.userModel = user
}
}
some.component.ts
export class SomeComponent implements OnInit {
userModel: UserModel;
constructor(private _userService: UserService) { }
ngOnInit() {
// It's a one time call and you control when you get (or `pull`) the data
this.userModel = this._userService.getUserModel();
}
}
Method 2: push based
Here the observable decides when you receive the data. This is the basic of reactive/asynchronous data flow. You subscribe to the data source and wait till it pushes the data. You have no knowledge when the result might arrive.
#Injectable()
export class UserService {
public userSubject$ = new Subject<any>();
getUserModel() {
return this.userSubject$.asObservable();
}
setUserModel(user) {
this.userSubject$.next(this.userModel = user);
}
}
some.component.ts
export class SomeComponent implements OnInit, OnDestroy {
userModel: UserModel;
closed$ = new Subject<any>();
constructor(private _userService: UserService) { }
ngOnInit() {
// The stream is open until closed and the service/observable decide when it sends (or `pushes`) the data
this._userService.getUserModel().pipe(
takeUntil(this.closed$) // <-- close the `getUserModel()` subscription when `this.closed$` is complete
).subscribe(
userModel => { this.userModel = userModel }
);
}
ngOnDestroy() {
this.closed$.next();
this.closed$.complete();
}
}
Angular uses observables extensively due to the nature of data flow in a typical web-application and the flexibility it provides.
For eg. the HTTP client returns an observable that you can latch on to and wait till the server returns any information. And the RxJS provides numerous operators and functions to refine and adjust the data flow.
I have a variable that stores the available cars at any moment. Is there a way to automatically re-evaluate this function on every change?
Just using this.carFactory.available in this case is not a solution, because this example I'm showing is simplified - the real calculation in my project is alot more complex.
calculateAvailableCars(){
this.carFactory.available.forEach(function(item){
this.availableCars.push(car.id);
}.bind(this));
}
How could I do this in Angular 2? In Angular JS there was the possibility to $watch a function.
I could of course manually call this function everytime something changes, but it would be nice not to have to call this function in every part of the application that can change the data.
Using template function reference with auto change detection
You can use this function output on template:
carOutput(): cars[] {
this.calculateAvailableCars()
return this.availableCars;
}
and use output on template:
<p>My car ratio is {{ carOutput() }} </p>
However this will trigger very aggressive change detection strategy on this variable. This solution is the simpliest one, but from engineering perspective rather worst: consumes tons of unnecessary function calls. One note, that hosting element must not be set to detect changes onPush.
Separate data model to parent component and pass as property to child
You can store car list display in separate component, and pass new car array as input property to this component:
<car-display [cars]="availableCars"></car-display>
Then you can set changeDetetcion policy in this component to onPush, and each time input property bind to availableCars will change, <car-display> will re-render.
If update relays on some host binding
If some external host action is triggering new cars calculation, then hostBinding may help:
#hostListener(`hover`) recalculateCars() {
this.calculateAvailableCars()
}
And finally, (because you describe your use case quite cryptically, without many details, thus I'm scratching all possible scenarios) if some external component action shall trigger re-calculation, you can hook to ngLifecycle ngOnChanges() if for example external input property change shall re-trigger cars calculation.
In other words and summing all that up, it depends who and from where triggers changes, that shall re-trigger available cars recalculation.
And very important, see an answer from #chiril.sarajiu, because what we are trying to work around here can be handled automatically by single observable. This requires additional setup (service, provide observable to components, e.c.t.) but it's worth.
--- EDIT ---
If each variable change shall retrigger data
As OP clarified, that changes are related with model bound to component. So another option with mentioned by #marvstar is using set, where each model variable change will retrigger fetching function:
modelSchangeSubject: Subject<Model> = new Subject<Model>();
ngOnInitt() {
this.modelSchangeSubject
.subscribe((v: Model) => {
this.calculateAvailableCars()
})
}
/* Rest of controller code */
set modelBounded(v: Model) {
this.modelSchangeSubject.next(v);
}
You need RxJS. What you do is you create a data service, which will store an Observable (in my case a BehaviorSubject, which is mostly the same, but in my case I start with a value).
export class DataService {
private dataStorage$ = new BehaviorSubject(null); //here is the data you start with
get getDataStorage() {
return this.dataStorage$.asObservable(); // so you won't be able to change it outside the service
}
set setDataStorage(data: any) {
this.dataStorage$.next(data);
}
}
Then you subscribe to this data changes everywhere you need to:
constructor(private dataService: DataService){}
ngOnInit() {
this.dataService.getDataStorage.subscribe((data) => this.calculateAvailableCars(data));
}
calculateAvailableCars(){
this.carFactory.available.forEach(function(item){
this.availableCars.push(car.id);
}.bind(this));
}
Read more about best practices of using RxJS in Angular, as there can be quite a bit of pitfalls and problems.
Try using setter and getter.
private _YourVariable:any;
public set YourVariable(value:any){
this._YourVariable = value;
//do your logik stuff here like. calculateAvailableCars
}
public get YourVariable():any{
return this._YourVariable ;
}
In some frameworks like Angular, you can inject services and controllers into one other like this
App.controller('exampleController', function($scope, ajaxService){
ajaxService.getData().then(function(data) {
//do something with the data
});
});
This is called Dependency Injection according to Angular docs
You can do something like this in Slim Framwork too, like this
$app->get('/example', function() use ($app, $db) {
$data = $db->getData();
//do something with the data
}
This is called Currying according to Slim docs.
As far as I see these are the exact same thing? Why are they called by different names?
Couple of interesting reading here: What is currying
What is dependency injection
No matter the programming language or framework, we could say "Dependency Injection" (DI) is something like
delegation at OOP Class definition (see example) and Currying is something totally different, let's say function parameter simplification.
DI allows you keep your classes simple and de-coupled. If you are familiar with Laravel, ServiceProvider are a good example. In a nutshell your class has a property which will be set to a instance of another Class (normally implementing an interface) so that you can delegate some functionality. Typical example is:
interface LogInterface {
public function write();
}
class LogToFile implements LogInterface {
public function write()
{
//Do something
}
}
class LogToFileDB implements LogInterface {
public function write()
{
//Do something
}
}
class MyDIClass {
private $log;
public function __construct(LogInterface $log){
$this->log = $log;
}
public function writeLog(){
$this->log->write();
}
}
//You can do
$myobj = new MyDIClass(new LogToFile);
//or you can do
//$myobj = new MyDIClass(new LogToDB);
//this will work, no worries about "write()" you are delegating through DI
$myobj->writeLog();
I've just written this code above (probably not functional) to illustrate DI. Using the interface you ensure the method "write()" will be implemented in any class implementing LogInterface. Then your class forces to get a LogInterface object when objects are instantiated. Forget how "write()" works, it is not your business.
In regards Currying, technique is diferent you just simplify the params in a function. When using Slim Framework the guys says "you can curry your routes by using $app". I've used Slim a lot and my understanding in that way is, ok, rathaer than pass several variables to your route closures just enrich your $app variable and pass 1 single var: $app
$app = new \Slim\Slim();
//Rather than
//$app->get('/foo', function () use ($app, $log, $store, ...) {
$app->get('/foo', function () use ($app) {
$app->render('foo.php'); // <-- SUCCESS
$app->log->write();
$app->db->store();
});
I want to write a reusable component as part of my Backbone app. Fundamentally I want to write a form filter helper so I can:
call a func inside a view js file which will create a drop-down which can listen to changes and then trigger changes in data and refreshes the view.
Ultimately I'd like to be able to do something like this:
// generic view.js
// to spawn a dropdown
formFilter('select', data);
// to spawn a series of checkboxes
formFilter('checkbox', data);
Obviously the module code would listen for events and handle the work.
My question is, what is the standard way of creating a reusable component? Google isn't giving me much and the #documentcloud IRC isn't particularly active.
Based on the information you've provided in your question, it's not easy to say how your particular component would be best componentized. However, one powerful strategy for reusability is mixins.
Simply you define the methods in a simple object literal, such as:
Mixins.filterable = {
filterForm: function(selector, data) {
this.$(selector)...
}
}
Mixins.sortable = {
sortForm: function(selector) {
this.$(selector)...
}
}
And then you can mix them into any View's prototype:
_.extend(FooView.prototype, Mixins.filterable, Mixins.sortable);
The mixin methods will then be available in all instances of FooView.
render: function() {
//..
this.filterForm('select', this.model);
}
Because the mixin methods will be bound to the context of the view instance, you can refer to this, and by logical extension, this.$el, inside the mixin methods. This will enable you to listen to the view's events:
Mixins.filterable = {
filterForm: function(selector, data) {
this.$(selector).on('change', this._handleFilterChange);
},
_handleFilterChange: function(e) {
//..
}
}
To make the methods available on all views, mix them into the Backbone.View prototype instead:
_.extend(Backbone.View.prototype, Mixins.filterable, Mixins.sortable);