Friday, 28 August 2015

Meteor And Rails

Rails the darling of startups could possibly give way to the new kid on the block, Meteor which is built on JavaScript. In Berlin at least, MEAN another set of JavaScript technologies has over taken Rails.[1]

Meteor has structural blocks and semantics that would resonate with Rails developers. In this blog post, I cover five such idioms common to both technologies. They are: i) templates ii) helpers iii) partials iv) fixtures, and v) routing. And also give relevant extracts from the books on Rails [2] and Meteor [3] on these aspects.

Before that, one cool thing is dynamic updates to the application when you change code. In both Rails and templates, unless in special cases, when you edit your code files, you don’t have to restart the server. Changes get reflected in the application dynamically. Now let’s get started.

In Rails, templates are a bigger concept. They are application templates, “which are simple Ruby files containing DSL for adding gems/initializers etc. to your freshly created Rails project or an existing Rails project.” [4]
In Meteor, templates are html code that create a connection between the screen and JavaScript code. As per the tutorial “everything inside template tags is compiled into Meteor templates, which can be included inside HTML with {{> templateName}} or referenced in your JavaScript with Template.templateName.” [5]

In Rails, helpers can be utility methods to perform some business logic [6]. However the standard way to use them in the context of view rendering only. That is, logic to be executed in the presentation layer is kept in helpers.
In Meteor, helpers are helpers for Templates and are either simple values or functions.

In Rails, partials contain “view” code that you reuse in multiple screens. Like the screen, they have the same name.html.erb file name, but start with an underscore.[7]
In Meteor, partials are just templates that can be called or included anywhere.

In Rails, for testing you populate the database with test data in files called as fixtures. The data format is YAML, and there is one file per entity. [8]
In Meteor, you put test data and functions that are executed at startup in fixtures.

In Rails, basically the concept is to map URLs to controller actions which is done in the file config/routes.rb
In Meteor, routes are used to associate a URL with a template. Meteor does not provide a built-in routing system, you can get it done using the Iron Router package.

Now the extracts. AWBR is the book on Rails [2] and DM is the book on Meteor [3].

DM : A template is a method of generating HTML in JavaScript. By default, Meteor supports Spacebars, a logic-less templating system, although there are plans to support more in the future. [pg 280]
In order to come to life, a template needs helpers. You can think of these helpers as the cooks that take raw ingredients (your data) and prepare them, before handing out the finished dish (the templates) to the waiter, who then presents it to you.
In other words, while the template’s role is limited to displaying or looping over variables, the helpers are the one who actually do the heavy lifting by assigning a value to each variable. [pg 29]

AWBR : It provides us with a bunch of form helper methods. These helpers interact with the controller and with the models to implement an integrated solution for form handling.[pg 162]
DM : When a template needs to render something more complex than a document property it can call a helper, a function that is used to aid rendering. [pg 279]

AWBR : You can think of partial templates (partials for short) as a kind of method for views. A partial is simply a chunk of a view in its own separate file. You can invoke (render) a partial from another template or from a controller, and the partial will render itself and return the results of that rendering. And just as with methods, you can pass parameters to a partial, so the same partial can render different results.
DM : Inclusions use the {{> templateName}} syntax, and simply tell Meteor to replace the inclusion with the template of the same name (in our case postItem ). [pg 28]

AWBR : In the world of testing, a fixture is an environment in which you can run a test. If you’re testing a circuit board, for example, you might mount it in a test fixture that provides it with the power and inputs needed to drive the functions to be tested.
In the world of Rails, a test fixture is simply a specification of the initial contents of a model (or models) under test. If, for example, we want to ensure that our products table starts off with known data at the start of every unit test, we can specify those contents in a fixture, and Rails will take care of the rest. [pg 85]
DM : The first thing we’ll do is put some data into the database. We’ll do so with a fixture file that loads a set of structured data into the Posts collection when the server first starts up. [pg 52]

DM : lib/router.js
Iron Router is a routing package that was conceived specifically for Meteor apps.
Not only does it help with routing (setting up paths), but it can also take care of filters (assigning actions to some of these paths) and even manage subscriptions (control which path has access to what data).
[To] install the package from Atmosphere:
meteor add iron:router [pg 74]
AWBR : config/routes.rb

[2] Agile Web Development with Rails 4 by Samy Ruby, Dave Thomas & David Heinemeier Hansson
[3] Discover Meteor by Tom Coleman and Sacha Greif

No comments:

Post a Comment