We Keep Coding

Mediate and share data between different modules

I am just trying to get my head around event driven JS, so please bear with me. There are different kinds of modules within my app. Some just encapsulate data, others manage a part of the DOM. Some modules depend on others, sometimes one module depends on the state of multiple other modules, but I don't want them to communicate directly or pass one module to the other just for easy access.
I tried to create the simplest scenario possible to illustrate my problem (the actual modules are much more complex of course):
I have a dataModule that just exposes some data:
var dataModule = { data: 3 };
There is a configModule that exposes modifiers for displaying that data:
var configModule = { factor: 2 };
Finally there is a displayModule that combines and renders the data from the two other modules:
var displayModule = {
display: function(data, factor) {
console.log(data * factor);
}
};
I also have a simple implementation of pub-sub, so I could just mediate between the modules like this:
pubsub.subscribe("init", function() {
displayModule.display(dataModule.data, configModule.factor);
});
pubsub.publish("init"); // output: 6
However this way I seem to end up with a mediator that has to know all of the module-instances explicitly - is there even a way to avoid that? Also I don't know how this would work if there are multiple instances of these modules. What is the best way to avoid global instance-variables? I guess my question is what would be the most flexible way to manage something like that? Am I on the right track, or is this completely wrong? Sorry for not being very precise with my question, I just need someone to push me in the right direction.

You are on the right track, I'll try to give you that extra push you're talking about:
It you want loose coupling, pub-sub is a good way to go.
But, you don't really need that "mediator", each module should ideally be autonomous and encapsulate its own logic.
This is done in the following way: each module depends on the pubsub service, subscribe to all relevant events and act upon them. Each module also publishes events which might be relevant to others (code samples in a minute, bear with me).
I think the bit you might be missing here is that modules, which use events, will hardly never be just plain models. They will have some logic in them and can also hold a model (which they update when receiving events).
So instead of a dataModule you are more likely to have a dataLoaderModule which will publish the data model (e.g. {data: 3}), once he finishes loading.
Another great requirement you set is sharing data while avoiding global instance-variables - this is a very important concept and also a step in the right direction. What you miss in your solution for this is - Dependency Injection or at least a module system which allows defining dependencies.
You see, having an event driven application doesn't necessarily mean that every piece of the code should communicate using events. An application configuration model or a utility service is definitely something I would inject (when using DI, like in Angular), require (when using AMD/CommonJS) or import (when using ES6 modules).
(i.e. rather then communicating with a utility using events).
In your example it's unclear whether configModule is a static app configuration or some knob I can tweak from the UI. If it's a static app config - I would inject it.
Now, let's see some examples:
Assuming the following:
Instead of a dataModule we have a dataLoaderModule
configModule is a static configuration model.
We are using AMD modules (and not ES6 modules, which I prefer), since I see you stuck to using only ES5 features (I see no classes or consts).
We would have:
data-loader.js (aka dataLoaderModule)
define(['pubsub'], function (pubsub) {
// ... load data using some logic...
// and publish it
pubsub.publish('data-loaded', {data: 3});
});
configuration.js (aka configModule)
define([], function () {
return {factor: 2};
});
display.js (aka displayModule)
define(['configuration', 'pubsub'], function (configuration, pubsub) {
var displayModule = {
display: function (data, factor) {
console.log(data * factor);
}
};
pubsub.subscribe('data-loaded', function (data) {
displayModule.display(data, configuration.factor);
});
});
That's it.
You will notice that we have no global variables here (not even pubsub), instead we are requiring (or injecting) our dependencies.
Here you might be asking: "and what if I meant for my config to change from the UI?", so let's see that too:
In this case, I rather rename configModule to settingsDisplayModule (following your naming convention).
Also, in a more realistic app, UI modules will usually hold a model, so let's do that too.
And lets also call them "views" instead of "displayModules", and we will have:
data-loader.js (aka dataLoaderModule)
define(['pubsub'], function (pubsub) {
// ... load data using some logic...
// and publish it
pubsub.publish('data-loaded', {data: 3});
});
settings-view.js (aka settingsDisplayModule, aka config)
define(['pubsub'], function (pubsub) {
var settingsModel = {factor: 2};
var settingsView = {
display: function () {
console.log(settingsModel);
// and when settings (aka config) changes due to user interaction,
// we publish the new settings ...
pubsub.publish('setting-changed', settingsModel);
}
};
});
data-view.js (aka displayModule)
define(['pubsub'], function (pubsub) {
var model = {
data: null,
factor: 0
};
var view = {
display: function () {
if (model.data && model.factor) {
console.log(model.data * model.factor);
} else {
// whatever you do/show when you don't have data
}
}
};
pubsub.subscribe('data-loaded', function (data) {
model.data = data;
view.display();
});
pubsub.subscribe('setting-changed', function (settings) {
model.factor = settings.factor;
view.display();
});
});
And that's it.
Hope it helps :)
If not - comment!

You do not need a mediator. Just import data, config, and display and call display(data, config) where you need to.
// import data
// import config
function render(){
display(data, config)
}

AngularJS reusable factory

I feel like this is probably a dumb question but I'm having trouble visualizing how to make this work.
I have a factory used to share data between controllers, like this:
app.factory('DataShare', function(){
//Share Data between controllers via the sharedItem object and the get/set functions
var sharedItem = {};
function set(sharedData){
sharedItem = sharedData;
}
function get(){
return sharedItem;
}
return{
set: set,
get: get
};
});
It works just fine. The issue is that are several times in my application where I need to share data. Currently, I have multiple factories with different names containing the same methods shown above. Can someone advise on the best way to create an abstract factory that I could reuse to share different data between different controllers?

Create a new file and declare a new object.
var mySharedLib = mySharedLib || {}; // declare a new namespace for the shared code.
mySharedLib.DataShare = function() {
// your factory logic
}
Then, the angular side:
app.factory('DataShare', mySharedLib.DataShare);

Pattern for sharing a library between angularjs and node.js

How can I share a library between angularjs and node.js?
For example an angularjs service is often a reusable piece of code. Let's take a URL library as an example (pick apart and construct URLs).
The same library should be usable in node.js.
My constraint is that I want to share the library code, but I do not want to restrict myself to any loader library on the browser side. So if I need to use RequireJS in the browser, I need to disable any loading part so that can be controlled elsewhere.
So how do I share code?

What you'll see in a lot of different places that support multiple environments is wrapping the entire returned value from your 'service' into a parameter passed to an initialization function from a closure. The one catch to keep in mind with angular is that service probably shouldn't have other dependencies to remain environment agnostic (If this was a simple utility file for example, there would not likely be conflict).
As an example consider:
(function( myService){
if (typeof module !== 'undefined' && module.exports ) {
module.exports = myService;
} else if( angular ){
angular.module('yourModule', [])
.factory('serviceNameHere', function(){ return myService; });
} else {
window.myService = myService;
}
}(function(){
function foo(){/* Do something */}
function bar(){/* Do something else */}
return {
foo: foo,
bar: bar
}
}()))
You could still have dependencies if desired via nodes require syntax, or angular's dependency injection, but the service would likely need modification as it moved from one project to another.

How to share filter between angular applications

This is probably simple question, but I cannot figure the answer.
I am developing several angular apps, I want to have one javascript file with all the filters I'm using.
Current I define the filters like this:
var app = angular.module('MyApp1')
app1.filter('filterCount',function() {
return function(input) {
....
}
})
How do I change my code to define this filter for any app that includes this file (e.g., if I want MyApp2 to use it)? Is there a way to do this?
Thanks.

Create a common module and inject it where ever you want.
var common = angular.module('common', []) //creates a module 'common'
common.filter('filterCount',function() {
return function(input) {
....
}
})
then
var myapp1=angular.module('myApp1',['common']);
var myapp2=angular.module('myApp2',['common']);

Can AngularJS auto-update a view if a persistent model (server database) is changed by an external app?

I'm just starting to familiarize with AngularJS, but I would like to build a web app that has a view that gets auto-upated in real-time (no refresh) for the user when something changes in the server-side database.
Can AngularJS handle this (mostly) automatically for me? And if so, what is the basic mechanism at work?
For example, do you somehow setup AngularJS to poll the DB regularly for "model" changes? Or use some sort of Comet-like mechanism to notify AngularJS client-side code that the model has changed?
In my application, the challenge is that other (non-web) server-side software will be updating the database at times. But this question applies equally to pure web-apps where you might have multiple clients changing the database through AngularJS web clients, and they each need to be updated when one of them makes a change to the DB (model).

You have a few choices...
You could do polling every X milliseconds using $timeout and $http, or if the data you're using is hooked up to a REST service, you could use $resource instead of $http.
You could create a service that uses some Websocket implementation and uses scope.$apply to handle changes that are pushed by the socket.
Here's an example using socket.io, a node.js websocket library:
myApp.factory('Socket', function($rootScope) {
var socket = io.connect('http://localhost:3000');
//Override socket.on to $apply the changes to angular
return {
on: function(eventName, fn) {
socket.on(eventName, function(data) {
$rootScope.$apply(function() {
fn(data);
});
});
},
emit: socket.emit
};
})
function MyCtrl($scope, Socket) {
Socket.on('content:changed', function(data) {
$scope.data = data;
});
$scope.submitContent = function() {
socket.emit('content:changed', $scope.data);
};
}
You could get really high tech and create a websocket implementation which syncs an Angular model with the server. When the client changes something, that change gets automatically sent to the server. Or if the server changes, it gets sent to the client.
Here's an example of that in an old version of Angular, again using socket.io: https://github.com/mhevery/angular-node-socketio
EDIT: For #3, I've been using Firebase to do this.

Here's an implementation that uses jetty instead node. The angularjs part is based on the angular-seed app. I'm not sure if the angular code is idiomatic...but I've tested that this works. HTH -Todd.
TimerWebSocketServlet see
https://gist.github.com/3047812
controllers.js
// -------------------------------------------------------------
// TimerCtrl
// -------------------------------------------------------------
function TimerCtrl($scope, CurrentTime) {
$scope.CurrentTime = CurrentTime;
$scope.CurrentTime.setOnMessageCB(
function (m) {
console.log("message invoked in CurrentTimeCB: " + m);
console.log(m);
$scope.$apply(function(){
$scope.currentTime = m.data;
})
});
}
TimerCtrl.$inject = ['$scope', 'CurrentTime'];
services.js
angular.module('TimerService', [], function ($provide) {
$provide.factory('CurrentTime', function () {
var onOpenCB, onCloseCB, onMessageCB;
var location = "ws://localhost:8888/api/timer"
var ws = new WebSocket(location);
ws.onopen = function () {
if(onOpenCB !== undefined)
{
onOpenCB();
}
};
ws.onclose = function () {
if(onCloseCB !== undefined)
{
onCloseCB();
}
};
ws.onmessage = function (m) {
console.log(m);
onMessageCB(m);
};
return{
setOnOpenCB: function(cb){
onOpenCB = cb;
},
setOnCloseCB: function(cb){
onCloseCB = cb;
},
setOnMessageCB: function(cb){
onMessageCB = cb;
}
};
})});
web.xml
<servlet>
<servlet-name>TimerServlet</servlet-name>
<servlet-class>TimerWebSocketServlet</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>TimerServlet</servlet-name>
<url-pattern>/api/timer/*</url-pattern>
</servlet-mapping>

What you are looking for is Firebase and Deployd.
Firebase comes with an adapter too that makes using it a breeze: http://angularfire.com/

According to the "Discover Meteor" book, Angular watches/scopes are similar to Meteor's computations regarding reactivity... but Angular is client-only and gives less-granular control than Meteor.
My impression is that using Angular might be a better fit for adding reactivity to an existing app, whereas Meteor soars when you use it for the whole thing. But I have no real experience with Angular yet (though I have built some small Meteor apps).

So, Andy Joslin has mentioned the best solution in my opnion in his answer, the 3rd option, which is to maintain state bidirectionally via websockets or whatever other async library you're dealing with (this would be the Chrome message API for Chrome Extensions and Apps for instance), and toddg has given an example of how that would be achieved. However, in his example he is implementing an anti-pattern in AngularJS: the service is calling the controller. Instead, the model should be placed inside the service, and then referenced from the controller.
The service socket callbacks will modify the service model, and because it is referenced from the controller, it will update the view. Careful if you're dealing with primitive data types or variables that can be reassigned though, those will need a watch on the controller to make this work.