Meteor.js – Meteor and Reactivity

WRITTEN BY GARETH DUNNE @JSDIARIES

A lot of Meteor’s strengths hail from its reactivity and real-time capabilities. We will look in to how these work while explaining how these real-time features can integrated with an API.

Reactive or declarative templating is a style of UI construction that contrasts the imperative approach in other words declarative templating communicates to and tells the computer how to do something and as a result what you want to happen will happen. The declarative approach however tells the computer what you want to happen and lets the computer figure out how to do it. Declarative templating separates the UI state, the underlying logical situation of what the user can see, from the layout being viewed (DOM). The user declares how the rendering technology should translate the state into the visual elements of the DOM. The state is then updated and the DOM adjusts accordingly.

A declarative rendering framework manages its complexity with an internal model of the core state of the page and this automatically changes the UI to reflect this model. To simplify this, what you see in your user interface or HTML markup will update itself automatically when our data is changed or edited.

Instead of waiting for a hard refresh our UI will reflect what has changed. The endless possibilities and ideas for real-time applications really become apparent once the functionality of declarative template is understood. Imagine all the possible data that we can extract from from an API. For example the Twitter Stream API.

To install this open up your cmd window with Node.js installed

npm install twitter

The Twitter Stream API returns a JSON object full of various different components of specified user’s Twitter timeline. Each different entity is stored in its own separate array.

Each additional object key in an entity is also stored in a nested array. The application has to iterate through various layers of nested arrays to retrieve the specified key of information that is to be displayed.

This depicts a sample Twitter Object that would typically contain keys holding different variables of a tweet own. In the next post I will be covering more detailed methods showing how to use the Twitter Stream API.

A typical Meteor.js application’s sync design is based on a singular JavaScript framework. JavaScript is usually single threaded and can only handle one event handler at a time. In a single-threaded environment, only one section of code can be running at any one time.

Single threading incurs blocking or synchronous tasks which means the system has to await a particular task to be finished and is unable to perform other tasks while waiting for it.

An asynchronous task can be initiated and then put aside while another task is executed. This is the concept behind Meteor’s synchronizing and event design.

In an application the Twitter Stream API can be used to retrieve information from Twitter timelines.

For a typical JavaScript framework the request would be made to the API and then the system would have to wait until it made a callback. This is not the case with Meteor, due to asynchronous use of the event loops. When the API makes a callback , that task can be concentrated on again. In order for this to happen JavaScript generates an additional background thread which takes care of managing the tasks of the event loop in order to prioritize the API tasks only when it has made a callback to the server.

Here is sample diagram of a the realtime sync by Toptal

Since Meteor is based on the Node.js framework , the server at runtime is single threaded. As a whole,  Node.js usually has more asynchronous operations, calling APIs and reading and writing files. So a basic callback can consist of up to three nested functions while more complicated operations can contain even more levels and sub-levels of other callbacks.

This may initially sound complicated., However, Meteor simplifies this by using a fiber package to deal with the way callbacks are made in this regard. The fiber package solves the issue of excess callback functions by abstracting away the asynchronicity using the Fiber sub-library called Future.

Meteor’s server automatically detects changes to any applications codebase, so pushing the new code to the clients prompts the client to reload. Even after an application has been deployed changes can occur and automatically update the applications client via hot-code pushes.

This post contains key fundamentals that will be used in the implementation of a typical Meteor.js application. Its good to know some of these concepts about reactivity that work under the hood of the Meteor.js architecture.

This post also reflects how a typical application will be implemented using Meteor.js and its unique isomorphic API.  It is used to structure the code and provide a dynamic reactive coding environment, giving any application that you make fluid real-time capabilities.

It will also make it easier to maintain and enhance in any future phases of an application that you have created where additional functionality might be considered. The Mongo vs Minimongo relationship that a typical Meteor.js application contains, provides a foundation to easily store any retrieved object or entity from an API. While the reactive environment allows any changes to these objects to be reflected back into the user interface instantaneously.

In the next post we will look at a more detailed implementation of the Twitter Stream API.