Develop Reference

JavaScript: Is the nesting of constructor instances inside a constructed 'wrapper' problematic?

Hopefully this question won't be flagged as too subjective but I'm newish to OOP and struggling a bit when it come to sharing data between parts of my code that I think should be separated to some extent.
I'm building a (non-geo) map thing (using leaflet.js which is superduper) which has a map (duh) and a sidebar that basically contains a UI (toggling markers both individually and en masse, searching said marker toggles as well as other standard UI behaviour). Slightly confused about organisation too (how modular is too modular but I can stumble through that myself I guess). I am using a simple JSON file for my settings for the time being.
I started with static methods stored in objects which is essentially unusable or rather un-reusable so I went for nested constructors (kinda) so I could pass the parent scope around for easier access to my settings and states properties:
function MainThing(settings) {
this.settings = options;
this.states = {};
}
function SubthingMaker(parent) {
this.parent = parent;
}
SubthingMaker.prototype.method = function() {
var data = this.parent.settings.optionOne;
console.log(data);
this.parent.states.isVisible = true;
};
MainThing.prototype.init = function() {
this.subthing = new SubthingMaker(this);
// and some other fun stuff
};
And then I could just create and instance of MainThing and run MainThing.init() and it should all work lovely. Like so:
var options = {
"optionOne": "Hello",
"optionTwo": "Goodbye"
}
var test = new MainThing(options);
test.init();
test.subthing.method();
Should I really be nesting in this manner or will it cause me problems in some way? If this is indeed okay, should I keep going deeper if needed (maybe the search part of my ui wants its own section, maybe the map controls should be separate from DOM manipulation, I dunno) or should I stay at this depth? Should I just have separate constructors and store them in an object when I create an instance of them? Will that make it difficult to share/reference data stored elsewhere?
As regards my data storage, is this an okay way to handle it or should I be creating a controller for my data and sending requests and submissions to it when necessary, even if that data is then tucked away in simple JSON format? this.parent does really start to get annoying after a while, I suppose I should really be binding if I want to change my scope but it just doesn't seem to be an elegant way to access the overall state data of the application especially since the UI needs to check the state for almost everything it does.
Hope you can help and I hope I don't come across as a complete idiot, thanks!
P.S. I think the code I posted works but if it doesn't, its the general idea I was hoping to capture not this specific example. I created a much simpler version of my actual code because I don't want incur the wrath of the SO gods with my first post. (Yes, I did just use a postscript.)

An object may contain as many other objects as are appropriate for doing it's job. For example, an object may contain an Array as part of its instance data. Or, it may contain some other custom object. This is normal and common.
You can create/initialize these other objects that are part of your instance data in either your constructor or in some other method such as a .init() method whichever is more appropriate for your usage and design.
For example, you might have a Queue object:
function Queue() {
this.q = [];
}
Queue.prototype.add = function(item) {
this.q.push(item);
return this;
}
Queue.prototype.next = function() {
return this.q.shift();
}
var q = new Queue();
q.add(1);
q.add(2);
console.log(q.next()); // 1
This creates an Array object as part of its constructor and then uses that Array object in the performance of its function. There is no difference here whether this creates a built-in Array object or it calls new on some custom constructor. It's just another Javascript object that is being used by the host object to perform its function. This is normal and common.

One note is that what you are doing with your MainThing and SubthingMaker violates OOP principles, because they are too tightly coupled and have too wide access to each other internals:
SubthingMaker.prototype.method = function() {
// it reads something from parent's settings
var data = this.parent.settings.optionOne;
console.log(data);
// it changes parent state directly
this.parent.states.isVisible = true;
};
While better idea could be to make them less dependent.
It is probably OK for the MainThing to have several "subthings" as your main thing looks like a top-level object which will coordinate smaller things.
But it would be better to isolate these smaller things, ideally they should work even there is no MainThing or if you have some different main thing:
function SubthingMaker(options) {
// no 'parent' here, it just receives own options
this.options = options;
}
SubthingMaker.prototype.method = function() {
// use own options, instead of reading then through the MainThing
var data = this.options.optionOne;
console.log(data);
// return the data from the method instead of
// directly modifying something in MainThing
return true;
this.parent.states.isVisible = true;
};
MainThing.prototype.doSomething = function() {
// MainThing calls the subthing and modifies own data
this.parent.states.isVisible = this.subthing.method();
// and some other fun stuff
};
Also to avoid confusion, it is better not to use parent / child terms in this case. What you have here is aggregation or composition of objects, while parent / child are usually used to describe the inheritance.

Lazy loading Pattern with Typescript

So with C# and other languages where you have a get and set assessor on properties, it's quite simple to build a lazy loading pattern.
I only recently started playing with Type Script and I'm trying to achieve something the same. I'm loading a Poco with most of it's properties via a Ajax Call. The problem can be described below:
export interface IDeferredObject<T> {
HasLoaded: boolean;
DeferredURI: string;
}
export class Library{
LibraryName: string;
Books: IDeferredObject<Book[]>;
}
export class Book {
Title: string;
UniqueNumber: number;
}
window.onload = () => {
//Instantiate new Library
var lib = new Library();
//Set some properties
lib.LibraryName = "Some Library";
//Set the Deferred URI Rest EndPoint
lib.Books.DeferredURI = "http://somerestendpoint";
lib.Books.HasLoaded;
//Something will trigger a GET to lib.Books which then needs to load using the Deferred Uri
};
Couple of questions:
I
Is a Interface even the right thing to use here?
I'd like to trigger a Load action when something accesses the Library Books Property. Is this even possible?
I know it's quite an open question, just looking for some guidance on how to build that pattern.
Thanks

Books could be declared as a property(see get and set in TypeScript) and in its getter you can start an ajax call. The only issue is that you cannot know when the ajax call will return and you don't want to block the code execution while value for Books is loading. You can use promise to solve your problem. The following code is using JQuery Deferred Object which is returned by $.ajax call (since 1.5 version).
One change - HasLoaded and DeferredURI. They should reside in "loader class" i.e. Library because in my example Library class is responsible for data retrieval.
export class Library {
private _loadedBooks: Book[];
public get Books(): any {
var result: any = null;
// Check first if we've already loaded values from remote source and immediately resolve deferred object with a cached value as a result
if(this.HasLoaded) {
result = $.Deferred();
result.resolve(this._loadedBooks);
}
else {
// Initiate ajax call and when it is finished cache the value in a private field
result = $.ajax(this.DeferredURI)
.done((values) => {
this.HasLoaded = true;
this._loadedBooks = values;
});
}
return result;
}
}
Then code consumer would use Books as following:
var library = new Library();
library.Books.done((books: Book[]) => {
// do whatever you need with books collection
});
For me this design is counter intuitive and user of this code would not expect the Books field/property to return a deferred object. So I would suggest to change it to method, something like loadBooksAsync(). This name would indicate that the code inside this method is asynchronous and hinting that return value is a deferred object which value would be available somewhere later.

Is an Interface even the right thing to use here?
Yes, using interfaces simplifies the coupling problems also in TypeScript
See also: Programmers: Why are interfaces useful?
I'd like to trigger a Load action when something accesses the Library Books Property. Is this even possible?
Yes, it is possible to implement any loading pattern you like. TypeScript is just JavaScript when it comes to code loading.
But, for small to medium sized applications the loading is usually not addressed at TypeScript level but is rather handled by the module loader and script bundler.
Supporting statement:
https://github.com/SlexAxton/yepnope.js#deprecation-notice
Deprecation Notice
...The authors of yepnope feel that the front-end community now offers better software for loading scripts, as well as conditionally loading scripts. None of the APIs for these new tools are quite as easy as yepnope, but we assure you that it's probably worth your while. We don't officially endorse any replacement, however we strongly suggest you follow an approach using modules, and then package up your application using require.js, webpack, browserify, or one of the many other excellent dependency managed build tools...
See also:
Stack Overflow: How do AMD loaders work under the hood?
Stack Overflow: When to use Requirejs and when to use bundled javascript?
Programmers: Practices for organizing JavaScript AMD imports

In meteor, can pub/sub be used for arbitrary in-memory objects (not mongo collection)

I want to establish a two-way (bidirectional) communication within my meteor app. But I need to do it without using mongo collections.
So can pub/sub be used for arbitrary in-memory objects?
Is there a better, faster, or lower-level way? Performance is my top concern.
Thanks.

Yes, pub/sub can be used for arbitrary objects. Meteor’s docs even provide an example:
// server: publish the current size of a collection
Meteor.publish("counts-by-room", function (roomId) {
var self = this;
check(roomId, String);
var count = 0;
var initializing = true;
// observeChanges only returns after the initial `added` callbacks
// have run. Until then, we don't want to send a lot of
// `self.changed()` messages - hence tracking the
// `initializing` state.
var handle = Messages.find({roomId: roomId}).observeChanges({
added: function (id) {
count++;
if (!initializing)
self.changed("counts", roomId, {count: count});
},
removed: function (id) {
count--;
self.changed("counts", roomId, {count: count});
}
// don't care about changed
});
// Instead, we'll send one `self.added()` message right after
// observeChanges has returned, and mark the subscription as
// ready.
initializing = false;
self.added("counts", roomId, {count: count});
self.ready();
// Stop observing the cursor when client unsubs.
// Stopping a subscription automatically takes
// care of sending the client any removed messages.
self.onStop(function () {
handle.stop();
});
});
// client: declare collection to hold count object
Counts = new Mongo.Collection("counts");
// client: subscribe to the count for the current room
Tracker.autorun(function () {
Meteor.subscribe("counts-by-room", Session.get("roomId"));
});
// client: use the new collection
console.log("Current room has " +
Counts.findOne(Session.get("roomId")).count +
" messages.");
In this example, counts-by-room is publishing an arbitrary object created from data returned from Messages.find(), but you could just as easily get your source data elsewhere and publish it in the same way. You just need to provide the same added and removed callbacks like the example here.
You’ll notice that on the client there’s a collection called counts, but this is purely in-memory on the client; it’s not saved in MongoDB. I think this is necessary to use pub/sub.
If you want to avoid even an in-memory-only collection, you should look at Meteor.call. You could create a Meteor.method like getCountsByRoom(roomId) and call it from the client like Meteor.call('getCountsByRoom', 123) and the method will execute on the server and return its response. This is more the traditional Ajax way of doing things, and you lose all of Meteor’s reactivity.

Just to add another easy solution. You can pass connection: null to your Collection instantiation on your server. Even though this is not well-documented, but I heard from the meteor folks that this makes the collection in-memory.
Here's an example code posted by Emily Stark a year ago:
if (Meteor.isClient) {
Test = new Meteor.Collection("test");
Meteor.subscribe("testsub");
}
if (Meteor.isServer) {
Test = new Meteor.Collection("test", { connection: null });
Meteor.publish("testsub", function () {
return Test.find();
});
Test.insert({ foo: "bar" });
Test.insert({ foo: "baz" });
}

Edit
This should go under comment but I found it could be too long for it so I post as an answer. Or perhaps I misunderstood your question?
I wonder why you are against mongo. I somehow find it a good match with Meteor.
Anyway, everyone's use case can be different and your idea is doable but not with some serious hacks.
if you look at Meteor source code, you can find tools/run-mongo.js, it's where Meteor talks to mongo, you may tweak or implement your adaptor to work with your in-memory objects.
Another approach I can think of, will be to wrap your in-memory objects and write a database logic/layer to intercept existing mongo database communications (default port on 27017), you have to take care of all system environment variables like MONGO_URL etc. to make it work properly.
Final approach is wait until Meteor officially supports other databases like Redis.
Hope this helps.

Using reflection, dynamically load require module

So I have a small requirejs application that needs to create instances of a dynamic list of classes in runtime. Basically, reflection. I've done quite a bit of reading, but I've been finding a lot of references to Typescript, which I'm not using.
The principal idea is that before requirejs is ready, an array is loaded with a list of classes that will be required. This array is given to requirejs after its main entry point and I hope to create an instance for each entry.
I have done some reading of Ben Nadal's blog here http://www.bennadel.com/blog/2320-extending-classes-in-a-modular-javascript-application-architecture-using-requirejs.htm and I like his pattern and think this would work well for some of the modules I plan to dynamically create.
I had a thought that I could do something like this:-
_.each(loader, function(dep) {
require([dep.name]);
});
With loader being the global loaded with the array list. This doesn't create an instance of the dependency though, which is what I want in this case, like so:-
new Carousel('Delboy');
new Carousel('Rodney');
new Carousel('Grandad');
This, in this example, would create an instance of 3 new carousels, each with a name as passed in via the constructor. I think I am missing something in my understanding, help is appreciated.

Each resolved AMD dependency is an AMD module, which means that it's either a singleton object or a function. In the post by Ben Nadel which you referred to, a distinction is made between "definitions" and "instances". A definition is a singleton, and from a definition (function) you can create multiple instances. In Ben's terminology, RequireJS will only give you the definitions, and it is up to you to create the instances.
So, the following should work for what you're trying to do:
define('Carousel', [], function (name) {
this.name = name;
});
var loader = {};
var carousels = ['Delboy','Rodney','Grandad'];
carousels.forEach(function (carouselName) {
require(['Carousel'], function (Carousel) {
loader[carouselName] = new Carousel(carouselName);
});
});

How to organize models in a node.js website?

I have just started experimenting with building a website using node.js, and I am encountering an issue when organizing the models of my project.
All the real world examples I have found on the Internet are using Mongoose. This library allows you to define your models in a static way. So you can write this:
// models/foo.js
module.exports = require('mongoose').model('Foo', ...);
// app.js
mongoose.connect(...);
// some_controller_1.js
var Foo = require('./models/foo');
Foo.find(...);
// some_controller_2.js
var Foo = require('./models/foo');
Foo.find(...);
But since I don't want to use MongoDB, I need another ORM. And all the other ORMs I have found don't allow this. You first need to create an instance, and then only you can register your models. Also they don't seem to allow access to the list of registered models.
So I tried doing this:
// models/user.js
var registrations = [];
module.exports = function(sequelize) {
var result = null;
registrations.forEach(function(elem) {
if (elem.db == sequelize)
result = elem.value;
});
if (result) return result;
// data definition
var user = sequelize.define("User", ...);
registrations.push({ db: sequelize, value: user });
return user;
};
Which I can use this like:
// some_controller_1.js
var Foo = require('./models/foo')(app.get('database'));
Foo.find(...); // using Foo
But these small header and footer that I have to write on every single model file are a bit annoying and directly violate the "don't repeat youself" principle. Also, while not a huge issue, this is kind of a memory leak since the "sequelize" object will never be freed.
Is there a better way to do, which I didn't think about?

You can find an article about handling models with sequelize here: http://sequelizejs.com/articles/express#the-application
You basically just create a models/index.js as described here: http://sequelizejs.com/articles/express#block-3-line-0
Afterwards you just put your model definitions within files in the models folder as pointed out here: http://sequelizejs.com/articles/express#block-4-line-0