JayData under the curtains – how JavaScript functions turn into network operations

Author: Peter Aron Zentai May 31st, 2012

, ,

We are in the process of creating the JayData provider developer walkthroughs until they are available this is the first of two posts that give you a little insider info – so that you can better understand the workings of the library.

The lifecycle of a predicate function

Let me jump into the middle of things and just focus on the filter method  of the $data.Queryable. It has three overloads, the first accepts a Boolean predicate function much similar to the ES5 array.filter’s predicate. (The other two let’s you specify your predicate with a string or with a self-crafted expression tree) Let’s take the simplest example:

The Abstract Syntax Tree

First of all the predicate function is parsed and an AST graph is built. Below is the JSON representation, at least the most interesting parts of it. At this point the only requirement against the predicate is that it is a syntactically correct JavaScript function.

It is worth noting that some primitive constant expressions are evaluated at this point. So these two predicates

produce the same AST.

AST instances are a little bit hard to work with, as they are far from semantic, representing only the raw code and not exactly the meaning of it. In the next steps we transform this content into more palatable forms.

The JavaScript Code Expression

JavaScript Code Expressions are language level expressions represented as instances of types from the $data.Expressions namespace. Some of the trivial express types are FunctionExpression that represents a call to a function, PropertyExpression which represents accessing a member of an object, SimpleBinaryExpression that has a left and right side plus and operand like equal, lessThen or multiply, and the ConstantExpression that stands for any constant values that appear in our predicate. Check them all at http://jaydata.org/api

The JavaScript code expression tree is produced with an AST visitor and below is what it looks like for the example predicate.

Not all JavaScript language features are supported (but most), only the subset that let’s you express a predicate or a projector. RC1 of the JayData library does not support multi statement code blocks and the variable assignment operator.

While creating the JavaScript Code Expression tree, expressions that are local only get evaluated and only their value get into the tree as ConstantExpressions. A local only expression is an expression that is only composed of references that are available on the client.

For example the following two predicates will generate the same computed JavaScript code expression tree.

Note that in RC1 version of JayData you are not able to delegate a local only expression to the storage side. In the released version you can use the asRemote() global function to wrap blocks that you don’t want to be evaluated on the client.

JavaScript Code Expressions are unaware of the underlying domain and are generally untyped (beyond basic type information inferred from variables and expression type results), and the requirement against it that client variable references must exists.

So you can write product.Nam   and within the realm of the JavaScript Code Expression this is quite valid as we don’t know anything about what a product is. You are however get an “Unknown global reference” or “Unknown property/method” exception if you make a typo: product.Name == windo.location.href.

You can use the Code Expression layer independent of any other components of JayData to provide custom predicate or projection based functionality. Here is how you can convert a function to it’s expression tree representations:

The JS Code Expression tree will be as follows.

The Domain Expressions

… coming …

, ,