Salesforce, mobile & Front end stories
by Antigoni Tsouri
Salesforce has its own proprietary language called Apex. Apex provides easy to build data views and because the out of the box interface is never enough, it also has it’s own front end proprietary language, Visualforce. Apex is very much a Java-like object-oriented language in syntax and grammar, however the concept of programming is rather Database — oriented. With Apex you can access and perform all the known DML actions on your data. Visualforce is a markup language with plenty of tags that essentially are ‘translated’ as html elements when the pages you have built are rendered. Furthermore Visualforce has out of the box JavaScript components that will enhance the flow of the UI. Take the two together, Apex + Visualforce and you have got a powerful combination of customizable views and data manipulation. There’s nothing you can’t do right?
Wrong. And here’s why: mobile and responsive design is something you can’t have with just Apex and Visualforce.
When we build a Visualforce page we have to build also an Apex class that is usually called the controller of that page. The Apex class holds the server data and based on the requests from the page, it can alter this data. Because we are making requests from the page, most of the time we have to use a Visualforce tag <apex:form>. This tag automatically puts on the page something that is called the ‘View State’. The View state of your page is essentially a hidden form field that holds things like the values of all other elements of your page, so that then it can pass these values to your controller. For a more comprehensive understanding you can consult this article: https://developer.salesforce.com/page/An_Introduction_to_Visualforce_View_State.
View state goes back and forth between the browser and the server transferring data, every time you click a button on the page. On the plus side it makes it a lot quicker to build customized pages but the downside is it can have serious performance impacts. In fact, because we live in the cloud that we all know and love, there is a limitation of 135K per view state. So you have to optimize your view state very well to avoid performance issues.
During a personal project to make an application available on desktop as well as across mobile devices I found myself confronted with all these issues, so I gradually started removing more and more of the standard salesforce code components, until I got rid of the <apex:form> tag. And how do I request data then? Simply with native html elements like <input> elements, which send the same requests as an <apex:form> tag. And you can go back and forth with the server with another technology that is called JavaScript Remoting. So essentially you are going towards the usual web model: HTML page, client-side controlling (JavaScript remoting) and server-side controlling (Apex to fetch your data).
Long story short, up until now to build an interactive, responsive and dynamic interface in Salesforce, we had to put together all the existing technologies that Salesforce provides us, plus native HTML, CSS and JavaScript. You maintain a nice speed by removing the view state, but that comes with having to manage the requests to the server by yourself, through HTML + JavaScript. This means that you have to get your head all around the front end world, which demands a different mind-set and sometimes may not be as easy as it sounds.
For mobile devices, Salesforce announced a couple of years ago a new framework called Lightning components. Lightning components is a bundle of components from all the technologies mentioned above: an Apex controller, the front-end page, a CSS script and a JavaScript script. Salesforce will bundle them together for you, so you don’t need to reference your scripts (CSS & JavaScript) in you page for example.
Here’s a quick example of how Lightning works: let’s say you create a component called ‘Registration Form’. The following files will be automatically created as part of your component: the ‘RegistrationForm.cmp’ which contains the markup of your component, two javascript files ‘RegistrationFormController.js’ and ‘RegistrationFormHelper.js’ that handle events in the component and a css file ‘RegistrationForm.css’. A couple of other files like documentation, design and svg files are also created but are outside the scope of this article so let’s look closer at the first files.
In your RegistrationForm.cmp you can have the following tag: <aura:attribute name=”firstName” type=”String”/> and you can manipulate the value of the attribute ‘firstName’ from your javascript controller with component.get(“v.firstName”) to get its value or component.set(“v.firstName”, name) to set its value, where ‘name’ is a JavaScript variable. The key here is that whatever attributes you have in your component are easily accessible from the client-side JavaScript controller with the ‘v.attributeName’ notation -where v stands for ‘view’- and vice versa methods in your controller are accessible from your component with ‘c.methodName’ -where c stands for ‘controller’- notation.
Component File
Controller File
At the time of writing, Salesforce has announced the big news we were all expecting: Lightning framework expands to the desktop apps under the name ‘New Lightning Experience’. All the processes described above to make something work in desktop and mobile, will now be done automatically from the Salesforce platform as opposed to previously having to manage this process by yourself. We will still have to get our heads around the front-end way of development of course. But on the bright side, a web app will be automatically responsive, interactive and dynamic. There’s not going to be server-reliance anymore, each time we interact with an app, and there’s not going to be a need to load your scripts as separate files.
So far, I was always keeping my hopes down about any new technology, framework, app that came along as so promising and innovative. Even when the lightning framework was announced from Salesforce I was quite apprehensive. For all the technical explanation I gave above, I was thinking that ok, we’ve got the mobile but what about an app that works everywhere, without having to work around it yourself so much?
It’s the first time in all my years as a developer that I am not keeping my hopes down anymore and I dare say, that Salesforce is pioneering by combining the power of the cloud with the power of client-side technologies. Of course lots has to be done still and Salesforce itself is admitting that by saying that things are still in ‘beta’. Trailhead for Salesforce: https://developer.salesforce.com/trailhead is an excellent way to find out more about lightning components, lightning experience and general Salesforce technical capabilites. It has more than 10 learning trails to follow and more than 40 individual modules, out of which approximately 20 are around Lightning technology. The information for Lightning components and Lightning Experience is explained in a very comprehensive and simple way at the same time and the best of all is that you get to earn trail badges and points when you complete challenges !
All it takes is signing up to a developer org — a salesforce free development environment: https://developer.salesforce.com/signup . You then automatically get access to trailhead and to developer forums for help.
I am waiting impatiently to get my hands on the new framework and start building a new promising world of web-apps for the ultimate user experience.
