Skip to main content

Top #5 Things you should know when moving to #LIGHTNING components from Visualforce

Hello New Year,

Those of you who have barely made it to the 1st, congrats. 2016 has been officially branded as the worst bringer of bad news and us, you and me, have survived and entered 2017. So once again congrats on making it here.

Last year, Salesforce shocked everyone by announcing Lightning, a fundamental and drastic change to the very core of salesforce delivery. The message was simple- this was a major transition in the IT services and if they have not already, all the customers would want their CRM on portal devices. When Lightning was announced, it was like relocating the passengers from a completely full Boeing 404, sturdy durable and slow to the superfast Mig 41 that could deliver fast, break the sound barrier and was efficient- only this was mid-air.

This was a paradigm shift, however, you may want to deny it, and it was fundamentally necessary. But like it or no, the shift happened. And suddenly there was a lot of material out there and every other product that was launched henceforth was labeled Lightning. The good old Visualforce developer that I am, stood behind the crowd in anticipation of what was happening. There were talks, there were webinars, there was stuff happening- and all at lightning speed.

Therefore, it took a while to sort through the noise, cut to the very basics and understand how Lightning works. That effort is now presented in front of you in form of five bullet points that will help you transition successfully to Lightning.

And so we begin, the most fundamental tip that will help you understand Lightning is-

1. Don't Panic

The classic #1 tip given for the average traveler across the galaxy comes in handy when we begin to understand Lightning. There is a lot of material out there for understanding lightning, ready-made components to be used in your code. Start small. If you are familiar with JavaScript you are already there. If not, start now.
Let me repeat this for you, JavaScript is the first step in your transition to Lightning. The golden rule to learning a new language is to write the "hello world" code. A simple code that will get the hang of things. Lightning follows the pattern of any Javascript-based programming language, like AngularJS. Familiarity with one is an added advantage, if not, start learning. Once you get a hang of things, it is really fun to work with.

One way to ease into lightning is to create a basic app fit for your purpose. The Salesforce trailhead gives you a good start into the same.

2. Adopt M-VC

We are programmed to think in an MVC model of programming. We write an apex controller that contains the business logic and queries, the Visualforce page that displays the data. 
A Lightning Component uses the same concept of MVC but here the business logic and display view are written together, while the controller is only used to fetch data. This is the pattern followed by a lightning component. If you have been working on Visualforce/Apex Controllers for a while, it will feel odd initially but once you get a hang of it, building a Lightning component is the best thing you will every do.

3. Write Components inside Pages

With Visualforce, we have practiced hard to write pages for our solutions. We over-use the PageReference apex code to navigate users through the Visualforce wizards. Lightning brings with the most important aspect missing in visualforce pages, it brings the inheritance to the table.
Think of this as writing only Visualforce components instead of Pages. You can further inherit that component into another specializes component for specific use.

4. Everything is in the name

One of the early mistakes I made was not naming the components in the log. If you have a large number of components on the same page and all of them are interacting at the same time, debugging them becomes the stuff of nightmares if you do not name them properly. Create a name attribute to the component that you create and then use this name in the log messages that are generated in the code. You will thank me later for this tip.

5. Javascript is Case Sensitive

A moment of pause to all those who wasted an entire day to realize the problem was onClick. Yes, Javascript is case sensitive. Therefore, if you have a habit of using CamelCase or Camelcase, make sure you maintain consistency. This stuff of nightmare pops up at an unsuspecting time, have faced it many times when trying to access the obj.fieldname but it should be Obj.Fieldname

Some resources that will help you ease into Javascript and further into Lightning:

JS the Right Way

Egghead.io

Trailhead (Duh uh)!

All the best and as always May the Force Be With you!

Popular posts from this blog

The curious case of the custom redirection on Salesforce Console

Every developer worth their salt knows that the easiest way of redirection from a page to another is by using everyone's favorite function

public PageReference redirect() { PageReference pageRef = page.peskyProblemRedirection; pageRef.setRedirect(true); return pageRef; }
And the method is called by adding it to the Action attribute of the CommandButton or link, which works like charm and the user is redirected to the page after completion of the action.
So why am I going back to the basics? Because this way of redirection causes a pesky little problem in using the Service Cloud or Sales Cloud console.

Let's illustrate the problem, let's say you have a visualforce page as follows:

<apex:page sidebar="false" showHeader="false" controller="myExampleController"> <apex:form > <apex:pageBlock > <apex:pageBlockButtons > <apex:commandButton action="{!Redirect}&qu…

Some PDF tricks on Visualforce: Landscape, A4, page number and more

The beauty of Visualforce is simplicity. Remember the shock you received when you were told the entire page renders as PDF if you just add renderAs=PDF to the Page tag.

For those who thought I spoke alien language right now, here is the trick, to render a page as PDF, we add a simple attribute to the <apex: page> tag

<apex: page renderAs='pdf'> This will render the entire page as PDF.

Now, say we need to add some extra features to the PDF. Like a page number in the footer or we need to render the page in landscape mode. Faced with this problem, I put on my Indiana Jones hat and went hunting for it in the vast hay-sack of the internet (read: googled extensively). Imagine my happiness when i found a big big page with many big big examples to solve the problem. The document I am referring to is from W3C, paged Box media.

Long story short, I now possess the ultimate secret of rendering the page in any format I want. So here are few tricks I learned from the page. To p…

Cache me if you can: What you should know before daring to set URL parameter on visualforce

If someone gave me a pence for every time there was an SOQL query in an APEX Class without using Limit or a condition during a code review, I could afford a Lamborgini this month. Sigh. If only. We make it a habit of going digging for data, at the very moment we need it. The crux of this problem happens when you have chain classes which are independent of each other. Each class needs the reference from a single record and we have to query for that record every single time.

While we don't see it, every SOQL query has a cost to it, and it does not go in my Lamborghini fund, however, it should. In a recent project, we had to construct an Account 360 page that could fetch information from different integration points. The page was also called using a live telephony integration, which could pass the phone number for the account. This required an ability to keep in context the Account that was on call.

Passing the Account id in URL parameter was a valid option, however, any manipulatio…