{"id":2886,"date":"2015-07-06T18:23:44","date_gmt":"2015-07-06T18:23:44","guid":{"rendered":"http:\/\/13.52.125.237\/?p=2886"},"modified":"2019-02-16T18:40:19","modified_gmt":"2019-02-16T18:40:19","slug":"conventions-for-isomorphism","status":"publish","type":"post","link":"https:\/\/sotaenterprises.com\/?p=2886","title":{"rendered":"JavaScript Functions That Run Beautifully on Client and Server"},"content":{"rendered":"

One of the compelling benefits of Meteor\/Node.js is that a single language, JavaScript, can be\u00a0used on client and server. \u00a0Meteor developers use the\u00a0word isomorphic<\/em>\u00a0to describe JavaScript code that has been written to run anywhere. \u00a0To\u00a0make that possible, your JavaScript functions must adhere to certain coding conventions.<\/p>\n

After some experimentation and false starts, we have devised helpful programming standards that foster isomorphic code.\u00a0\u00a0I will share these standards with you through concrete examples.<\/p>\n

I’m currently working on an MVP for a startup called Pract.us. \u00a0This system uses a variety of\u00a0Meteor packages, plus some custom-written UI code to\u00a0deal with forms, animations and so on. \u00a0In contrast\u00a0to this “mechanical” code, which has nothing to do with the problem domain, the system has\u00a0dozens\u00a0of\u00a0domain functions<\/em> which\u00a0are germane exclusively\u00a0to Pract.us. \u00a0Many\u00a0of these\u00a0domain functions can be classified either as queries<\/em> or transactions<\/em> because they either read from or write to the database.<\/p>\n

Domain functions are the heart\u00a0of the system. \u00a0They encapsulate logic that updates the database in response to UI events. \u00a0A large part of the Pract.us development effort goes into\u00a0writing and refining these domain functions.<\/p>\n

In Pract.us, a UI event handler will usually\u00a0delegate to one or more domain functions. \u00a0The domain function(s) will perform\u00a0a number of database queries and updates, and some of them are complex, involving updates to several collections.<\/p>\n

Pract.us\u00a0domain functions are anchored<\/em> in a global JavaScript object named\u00a0Practus<\/strong>. \u00a0Because Pract.us is a small system, it is feasible to anchor all<\/em> domain functions in Practus<\/strong>.<\/p>\n

Domain functions are technically\u00a0stateless<\/em> because they have no instance variables. \u00a0They operate exclusively on passed parameter values and data stored in Mini-Mongo and\/or MongoDB.<\/p>\n

To facilitate isomorphism, we\u00a0first declare a\u00a0Practus<\/strong> anchor object\u00a0in a Meteor project folder that is shared by both\u00a0client and server:<\/p>\n

Practus = {};<\/code><\/p><\/blockquote>\n

Next, we\u00a0create three JavaScript files named practus.js<\/strong>: one in a client folder, one in a server folder and one in a shared folder. \u00a0All three files contain the following skeletal code:<\/p>\n

\/*
\n * Pract.us domain functions.
\n *\/
\n\"use strict\"
\nPractus = _.extend(Practus || {}, {
\n \/\/ *** DOMAIN FUNCTIONS GO HERE ***<\/strong>
\n});<\/code><\/p><\/blockquote>\n

By using the Underscore extend<\/strong> function, we’re appending functions to the Practus<\/strong> anchor object. \u00a0Since shared functions are visible to both<\/em> client and server, this results in the following arrangement:<\/p>\n