I'm writing a directive which creates an mp3/audio player. The issue is that you can have many audio players in one page. What I would like to do is when one is playing and you start an other, that the one currently playing pauses. How can I achieve this with angular directives?
Thanks in advance!
Make a service that each directive uses and hold the state in there.
Something like this:
angular.module('MyPlayer' [])
.factory('playerState', function() {
var players = [];
return {
registerPlayer: function(player) {
players.add(player);
},
unregisterPlayer: function(player) {
var i = players.indexOf(player);
(i>-1) && players.splice(i,1);
},
stopAllPlayers: function() {
for(var i=0;i<players.length;i++) {
players[i].stop();
}
}
}
})
.directive('player', function(playerState) {
return {
...
link: function(scope, elem, attr) {
var player = {
stop: function() {
/* logic to stop playing */
},
play = function(song) {
playerState.stopAllPlayers();
/* logic to start playing */
}
}
playerState.registerPlayer(player);
scope.$on("$destroy", function() {
playerState.unregister(player);
});
scope.play = player.play;
scope.stop = player.stop;
...
}
}
})
Just to make the answers complete, next to broadcasting events, and exposing a service, you can also use directive controllers. These controllers are set through the controller property of a directive definition object and are shared between directives that require the same controller. This means you can have one controller for all the media players, where you can implement the logic you mentioned. See the documentation on directives (search for controller:) for more information.
I would recommend the service approach if you think there will be more consumers of the logic, or the directive controller approach if only the directives consume the logic. I would advise against broadcasting events on the root scope because of the uncoupled and global nature of it. Just my two cents! HTH
How are your directives setup? Please provide some code.
This depends on the scope of your directives, I'm going to assume a child scope. To communicate between the directives, when a user clicked to start a player, I would call a $scope.$parent.$broadcast() - or $rootScope.$broadcast() if the directives are in different controllers or using isolated scopes, but then you need to inject $rootScope into your directive - to send an event to all child scopes. My directives would be watching for this event using $on and any players that were playing would stop. After this broadcast the player clicked would start.
$broadcast() and $on() scope documentation
You can also do $rootScope.$broadcast events like playerStarted. This event can be subscribed by all directives and they can react to this event by stopping themselves. The one thing that you need to do would be pass in the data about the player which is starting so that the new player does not stop itself as it too would subscribe to such event.
Related
This is my page's structure.
// app.html
<wrapper ng-if="initialized && $root.user.type!='guest'">
<header-component></header-component>
<div class="app-body">
<sidebar-component></sidebar-component>
<main class="main-content" style="height:{{$root.pageHeight}}px; overflow-y: scroll">
<ng-view></ng-view>
</main>
<aside-component></aside-component>
</div>
</wrapper>
Now in ng-view directive I have a controller which needs to pass data to the header-component.
As you can see, ng-view is not associated to header-component in some way.
Let's say that ng-view controll now screen is:
// some-screen.js
$scope.foo = "bar";
And I want to display bar in the header.
I can do this both with $rootScope (without any event) or using the $broadcast event.
First method - using the $rootScope - as it is - without just anything:
// some-screen.js
$rootScope.foo = "bar";
// header.js
app.directive("headerComponent", ($rootScope) => {
return {
templateUrl: "/structure/header/header.html",
scope: {},
link: function($scope, element, attrs) {
console.log($rootScope.foo) // "bar"
}
}
});
Second method - using the $broadcast event
// some-screen.js
$rootScope.$emit("SomeNameOfTheEvent", $scope.foo);
// header.js
app.directive("headerComponent", ($rootScope) => {
return {
templateUrl: "/structure/header/header.html",
scope: {},
link: function($scope, element, attrs) {
$rootScope.$on("SomeNameOfTheEvent", function(event, info) {
console.log(info.foo) // "bar"
});
}
}
});
Now notice two things while using the $broadcast event:
You need to specify name for this event - in big app this can be tricky - since
you probably ain't going to remember the names you throw while coding.
And sitting and think of good names is a waste of time.
You will probably need to make a documentation in order to re-use the event name from other places
in the app - otherwise you will mistakely try to use the same event but with wrong names.
They are both doing the same - $broadcast just takes more code to function.
What am I missing, AngularJS probably created the $broadcast event for something.
$emit dispatches an event upwards ... $broadcast dispatches an event
downwards
Detailed explanation
$rootScope.$emit only lets other $rootScope listeners catch it. This is good when you don't want every $scope to get it. Mostly a high level communication. Think of it as adults talking to each other in a room so the kids can't hear them.
$rootScope.$broadcast is a method that lets pretty much everything hear it. This would be the equivalent of parents yelling that dinner is ready so everyone in the house hears it.
$scope.$emit is when you want that $scope and all its parents and $rootScope to hear the event. This is a child whining to their parents at home (but not at a grocery store where other kids can hear).
$scope.$broadcast is for the $scope itself and its children. This is a child whispering to its stuffed animals so their parents can't hear.
We have various components in the application that are not in parent/child or sibling relationships. Let's say a checkbox that when in checked state is supposed to change the state of another component which is in a completely different container.
The application is over 500 different views, so a controller for each one is not an option. Those interactions are also completely custom, so we would need tens of methods to cover all of them (checkbox to tab, multiple checkboxes to tab, multiple checkboxes to more checkboxes etc).
What is the best course of action here? So far we thought about a globally available service to register components by id and then subscribe the dependent components to listen for the status change on that particular id in the service (for example in an ng-if directive to toggle), or use Redux. We have no previous experience with complex relationships like that.
Any ideas or similar experiences would be greatly appreciated.
The Observer pattern as you describe it is being implemented in angularjs with event emmiters ($broadcast $emit) so there is no need to create an independent service.
The point of component based applications is to have some tree structured architecture. So in those cases the child component notifies the parent and then the parent notifies some other child maybe and goes on.
If your application is not structured like this you might consider a refactoring but for now you could just bind some event emitters.
To solve this issue use the publish/subscribe pattern that allow get a loosely-coupled architecture.
On an AngularJS application a great library is postaljs that allow implements this pattern easely:
Define at app.config a $bus $scope variable that will be accesible on all places of the application: controlers, directives, ...
app.config(function($provide) {
$provide.decorator('$rootScope', [
'$delegate',
function($delegate) {
Object.defineProperty($delegate.constructor.prototype,
'$bus', {
get: function() {
var self = this;
return {
subscribe: function() {
var sub = postal.subscribe.apply(postal, arguments);
self.$on('$destroy',
function() {
sub.unsubscribe();
});
},
channel: function() {
return postal.channel.apply(postal, arguments);
},
publish: function() { postal.publish.apply(postal, arguments); }
};
},
enumerable: false
});
return $delegate;
}
]);
});
Publish
Publish on item updated.
var channel = $scope.$bus.channel('myresources');
channel.publish("item.updated", data);
Publish on list updated
var channel = $scope.$bus.channel('myresources');
....
channel.publish("list.updated", list);
Subscribe
The controller/directive that needs be notified for an event on the "myresources" channel.
var channel = $scope.$bus.channel("myresources");
....
//The wildcard * allow be notified on item/list. updated
channel.subscribe("*.updated", function(data, envelopment) {
doOnUpdated();
});
Consider two nested directives with isolate scopes:
<dctv1>
<dctv2></dctv2>
<dctv1>
If I want dctv2 to talk to dctv1 I have may options:
I may require the controller of dctv1 in the definition of dctv2 using the require:'^dctv1'
I may call an expression on the parent scope with the wrapper <dctv2 callParent="hello()"></dctv2> and scope:{callParent:'&'}
I can also use $scope.$emit in dctv2 but then all parent scopes will hear the message.
Now I want dctv1 to talk to dctv2.
The only way I may accomplish this is to use $scope.$broadcast, but then all children will hear.
By talk to here i mean call a function or similar. Don't want to set up watches clogging the digestloop.
How can I make dctv1 notify dctv2 in the best way, making them loose-coupled? I should just be able to remove dctv2 without errors.
Take a look at AngularJS NgModelController for some ideas.
Each <dctv2> directive would require <dvtv1> to have it's controller injected. You can then add objects or callbacks to properties of that controller, and remove them when <dctv2> is destroyed.
<dvtv1> would not talk directly to children, but would trigger callbacks bound to it's properties.
For example;
NgModelController has $parsers and $formatters that are an array of function callbacks. You push your own functions into the array to extend that controllers behavior.
When NgModelController performs input validation it's basically talking to other directives via these properties.
I would suggest using angular services. That way you can decouple your behavior into one or more services.
Take a look at this also : AngularJS : How to watch service variables?
One way is to make a Service/Factory that will communicate with the controllers that you want.
For example, here's a getter/setter Factory
.factory('factoryName', function () {
var something = "Hello";
return {
get: function () {
return something;
},
set: function (keyword) {
something = keyword;
return something ;
}
};
}])
And then in your controllers:
.controller('controllerOne', ['factoryName', function (factoryName) {
$scope.test = factoryName.get();
}]);
.controller('controllerTwo', ['factoryName', function (factoryName) {
$scope.test = factoryName.get();
$scope.clickThis = function (keyword) {
factoryName.set(keyword);
};
}]);
I suggest reading up on this : Can one controller call another?
You can manage it using an id for each child that have to be passed to the parent; the parent will broadcast back the event using that id: the child will do the action only if the id passed from the parent is the his own.
Bye
I'm building a growl like UI in angular. I'd like to expose it as a factory (or service) to make it available in my controllers. Calling growl.add will result in a change in the DOM, so it seems like I should have a directive take care of that, rather than doing direct DOM manipulation in the factory. Assuming that a factory-directive combo is the best option (and please correct me if that is not a good assumption), the question is:
How best to communicate between the factory and the directive?
Specifically, how best to send messages from the factory to the directive? Other questions have well covered sending information the other way, with onetime callback.
See below the working example. I suspect there is a better way though..
For reference, I have played with other options:
A) have the directive watch the service, e.g.
$scope.$watch(function(){
growl.someFunctionThatGetsNewData()},
function(newValue){
//update scope
})
But this means that someFunctionThatGetsNewData gets called in every digest cycle, which seem wasteful, since we know that the data only gets changed on growl.add
B) send an 'event', either via routescope, or via event bindings on the dom/window. Seem un-angular
Since neither of those options seem good, I'm using the one below, but it still feels hacky. The register function means that the directive and the factory are tightly coupled. But then again from usage perspective they are tightly bound - one is no good w/o the other.
It seem like the ideal solution would involve declaring a factory (or service) that includes the directive in its declaration (and perhaps functional scope) so that it exposes a single public interface. It seems icky to have two separate publicly declared components that entirely depend on each other, and which have tight coupling in the interfaces.
Working example - but there must be a better way..
vpModule.directive('vpGrowl',['$timeout', 'growl', function ($timeout, growl) {
return {
template: '<div>[[msg]]</div.',
link: function($scope, elm, attrs) {
growl.register(function(){
$scope.msg = growl.msg;
});
$scope.msg = growl.msg;
}
};
}]);
vpModule.factory('growl', ['$rootScope', '$sce', function($rootScope, $sce) {
var growl = {};
growl.msg = '';
var updateCallback = function(){};
growl.add = function(msg){
growl.msg = msg;
updateCallback();
};
growl.register = function(callback){
updateCallback = callback;
};
return growl;
}]);
I would have your growl service decide what to show, not the directive. So, the service handles any timers, state, etc. to decide when to hide/show messages. The service then exposes a collection of messages which the directive simply binds to.
The directive can inject the service and simply place it in scope, and then bind an ng-repeat to the service's collection. Yes, this does involve a watch, but you really don't need to worry about the performance of a single watch like this.
link: function(scope, elm, attrs) {
scope.growl = growl; // where 'growl' is the injected service
}
and then in the directive template:
<div ng-repeat="msg in growl.messages">
...
</div>
I would implement following logic:
Service growl defines some property growlProp on $rootScope & update it on each call of growl.add
Directive set watcher on $rootScope.growlProp
So directive knows nothing about service & service knows nothing about directve.
And additional overhead related to watcher is minimum.
I am wondering if there is a convention within AngularJS for creating an object that lives within the app module, but is not attached directly to the view in any way, but is called when the view has loaded and the app starts up. In particular, I am trying to write an object that dispatches messages to listening controllers when they come in from the server.
Currently, I have implemented this by creating a "Controller" that attaches to the view. It has a monitor() function that is called when the page loads, and then listens in a loop for any incoming messages. I call the monitor() function from within the loaded view, by setting the ng-controller like so:
<div ng-controller="MyController">
{{ monitor() }}
</div>
This doesn't feel like the right thing to do. This "Controller" isn't interacting with the view in any way, so my gut tells me I am violating principles of AngularJS. But I haven't been able to turn up an easy solution that is endorsed by the AngularJS doc.
I am looking for a way to create an object that lives within the AngularJS world (in other words, it can use dependency injection to get access to services, and it can use $scope.$broadcast to send messages to other listening controllers), but that doesn't need to attach itself to the view in any way.
Ideally, I am looking for a way to say, "Here Angular, on startup, create this object, and run this method on it." Is there a way to do this?
You may use this as a starting point:
declaration of your object.
AngularJS: Service vs provider vs factory
myApp.factory('MessageBus', function() {
return {
listeners: [],
init: function() {
// do whatever you need at startup
},
pushMessage: function(msg) {
angular.forEach(this.listeners, function(listener) {
listener(msg);
});
},
subscribe: function(onMessageCallback) {
this.listeners.push(onMessageCallback);
}
};
});
calling a method on angular appilcation start
https://docs.angularjs.org/api/ng/type/angular.Module#run
myApp.run(function(MessageBus) {
MessageBus.init();
});
using this object within controllers
https://docs.angularjs.org/guide/di
myApp.controller('MessageCtrl', function($scope, MessageBus) {
$scope.messagesToShow = [];
MessageBus.subscribe(function(message) {
$scope.messagesToShow.push(message);
});
$scope.submitMessage = function(id, text) {
MessageBus.pushMessage({
type: 'TEXTMESSAGE',
id: id,
payload: text
});
};
});
Note that this is something to start with and nothing for any production code. For example the controller doesn't unsubscribe after being destroyed - if the page changes - and so you leak memory.
Don't use $broadcast-events for this
1: they are slow
2: if this MessageBus has a specific concern, than in should be an own object with a meaningfull name and api. Otherwise your $rootScope will be flooded with thousends of different events for different concerns when your application grows. A service is always easier to document and you have a clean dependency on that specific service. Only using events on the $rootScope hides this dependency from every developer reading and hopefully understanding your codebase,
Yeah you approach is really smelly. This function will be called every time a $apply/$digest invokes.
Maybe move the function into the run callback on the module.
var app = angular.module("YourApp", [//dependencies]);
app.run(function($YourUIService){
$YourUIService.monitor();
});
The run will be invoked, when your angularjs-module has loaded every dependency and is ready to run.
Didn't find the doc for this :/