In the Scope of Visualforce

As anyone who has had any kind of Visualforce related discussion with me in the last few months already knows, I am extremely excited for the new Remote Objects feature being offered as a Developer Preview in Spring ’14.  JavaScript Remoting has revolutionized how developers can build Visualforce pages and Remote Objects looks to take it to the next level.

Core to why I think developers will love this feature is that it makes it easier to create applications and interfaces which remain within the scope of Visualforce.  Visualforce provides a container where developers can intermingle HTML, JavaScript, CSS while also binding to dynamic server-side components.  This provides a high degree of flexibility from simply adding an apex:detail to a page to emulate a record’s layout all the way to controlling the interface implicitly with JavaScript libraries.

Back in the day, you did all of your server-side logic via the SOAP API requests and still isn’t entirely uncommon to use the REST API within JavaScript.  However, there are two key drawbacks to this: one is that without being bound to a Visualforce component (like apex:form), Visualforce has no chance to perform any kind of sanity check on the request.  Second is the fact that you are consuming API hits with every call, which count against your daily limit.  To keep developers within the scope of Visualforce, we added JavaScript Remoting.  Now we have Remote Objects to make things even easier.

What are Remote Objects?

In case you missed the Spring ’14 preview webinar, Remote Objects allows developers to interact with data via JavaScript without having to write Apex to define the server-side functionality.  Andrew Fawcett also posted a great introduction to Remote Objects recently, and you might also check out this post from OyeCode which gets bonus points for testing it in Salesforce1.  You can also get a full overview from the release notes themselves.

The comparison could be made between Remote Objects and Standard Controllers as they both allow for basic CRUD (create, read, update, delete) and queries against data with only client-side code.  However, I would actually argue that Remote Objects are more powerful, or at least more flexible, as they aren’t tied specifically to one kind of object. While the feature was being developed, we wanted to make sure that things were being kept friendly with JavaScript frameworks in general.  To test this out, I wanted to try out a new framework I had not used before and after reading this comparison on new frameworks I ended up downloading CanJS.  For client-side MVC, CanJS is a great lightweight and versatile option for JavaScript developers.

Getting Started with Remote Objects

To use Remote Objects, we declare the model that we are going to need with the Visualforce components.  The components for Remote Objects allows the platform to properly construct the resulting JavaScript for use while also being able to do things like perform a check on the data model.  This way you’ll get an error if you are trying to build against fields or objects which simply aren’t there.

For this demo, we’ll setup a simple model for editing contacts:

Once we have that we can start define our models from both Remote Objects and with CanJS:

And we can use both to define the functionality of a collection in CanJS:

And include functionality like updating a record off an event:

Since we have tied the Remote Objects collection to our CanJS collection, we can call the methods we get from SObjectModel directly in reaction to the event.  Now we can bind this all to a Mustache style template:

And we have a working table that displays, edits and deletes contact data … all without a single line of Apex having been written.

You can see the full version at this gist.

A Time and Place for Everything

Remote Objects are a great new tool but it is important to note that you aren’t going to start writing all of your applications exclusively with them.  Remote Objects are not intended to be a replacement for using Apex when it makes sense to bundle custom logic into a method.  Their purpose is, as noted before, similar to that of a Standard Controller – it keeps developers from having to re-invent the wheel every time they want to do simple CRUD logic within a JavaScript based application.  There probably are entire applications which can be rewritten with Remote Objects and remove Apex as a requirement, but developers should not try to fit a round peg into a square shaped Remote Object.