Lightning is relatively a new concept in Salesforce world and we are going to take a detailed view what does the term ¨Lightning’’ mean, what are its main advantages or disadvantages, and what are the requirements for IT companies.
At the very beginning, let’s look at the Lightning fundamentals. The key terms of today’s IT world are undoubtedly cloud and big data, but the lightning concept can be sometimes viewed as the step back. The question is why one the most leading companies of the cloud solutions decided for the technology that seems to be anti-cloud.
What is Salesforce Lightning?
We still do not know exactly what does the Lightning mean. Shortly explained from the client’s point of view (computer, notebook, smartphone, etc..), it is an application, using the advanced specifications of the modern web browsers, that represents the core of its structure. As a result, such an application doesn’t have to be similar to the browser and the user does not differentiate it from any other software being installed.
Now we can consider if there is still any connection to the cloud concept. What do you think? You are right, Lightning has a lot of common with the cloud concept. In fact, the application is not installed, only ¨borrowed¨ from the cloud and all the data produced by such an application remain the part of the cloud that brings a lot advantages, but also some disadvantages. The biggest advantage is the cloud itself that means independence, availability, and the safety of the solution. The biggest disadvantage of the cloud is its relative speed, overworked server and slow connection. And now we are getting to the real point of this article.
Due to its speed, the Lightning process belongs to very attractive attributes of the future. Although the first step takes more time as the code needs to be loaded from the server, the final effect of using such an application is unreplaceable (in case it is designed in a good way) because it is like Salesforce would be installed directly in your equipment.
Usually, everybody has enough “computing power in his pocket” (equipment like smartphone),and the part of the server workload is transmitted to your equipment.
But let’s now discover the creation of the lightning application.
What does MVCC mean for the designer? I would say a “horrible headache’’ because it is really a brainteaser. Components like lego cubes play a key role, every component can include:
- controller on the client side
- controller on the server side
- events that serve for data sharing with other components
And this can be combined in any way, when we try to count it, we find out that only component itself can be designed in eight different ways.
The application itself does not have to include any component, or can include only one component or numbers of components. Controller on the server side can be shared by several components as it contains only basic CRUD operations over the components. Are these informations sufficient? Or would like to learn more? So let’s continue.
If the application is divided into many integrated components that contain controllers it will be possible to reuse them in another application. That means they will be completed and tested that will result in time and cost saving, also it can be considered as a good investment for the future projects.
But be careful as there is a risk of devastating the main advantage of the Lightning that is its SPEED, ultimately this can influence the user’s impression.
In this part we are going to pay attention to our developers with rich experience and knowledge of HTML, CSS and JS. I am not going to focus on their usage in Lightning but only on the basic features that makes AURA to be an unique framework. If you are not a technical type I recommend skipping the next part as it can be a really boring reading for you.
I will start with controller on the side of server.
Everything remains the same, the only change is in adding of @AuraEnabled annotation and do not forget that communication with controller on the client’s side is performed by json format. Unfortunately, it is not supported by the advanced data types as SelectOption that would be transformed to json at the background. But if you are a little bit inventive it can be reached by Map class.
Now, we are switching to the most important part regarding AURA.
It is necessary to understand the power of AURA address structure, that in fact produces the particular namespaces that serve for getting to particular components, interfaces or events.
Every namespace includes application (.app), component (.cmp) event (.evt) or interface (.intf).
1., Namespace event includes only one folder that serves as a public folder that is updated in all components naray by using the method fire () from any component.
2., Interface also includes only one folder that consists of several events and attributes which will be described later. It is important to mention that it can be used in the head of the component by using the keyword ¨implement¨ and serves then as a classic interface in OOP. There can be implemented more interfaces in the head of the component. From the programmer point of view, the difference between component and application is only in the head of the component, otherwise it consists of the same folders and features. Application can be launched in the browser, comparing to the component.
3., The component is a folder in namespace similar to visualforce page, but consisting of the specific tags. The key tags that are designed for the manipulation with changes are:
aura: attribute serving as a public change of the component
aura: registerEvent – the component is added to the event
aura: handler – can be used as a constructor of the component
I am not going to mention other tags as they are used mostly for displaying and there are a lot of them as well as html tags.
Now, let me mention very important thing we should bear in mind. All the folders, except .cmp and .app, are visible only within its namespace.
1., Controller consists of action (methods) with the strictly specified parameters containing component event (be careful, it refers only to events within component) and helper. It serves for the processing of the all events from the browser, communication with the controller on the side of the server and most of the logic of the component.
The main purpose of the article was not to introduce the tutorial to AURA, but only to sketch its using so if somebody is interested in, then it is the best time to use AURA documentation.
The development itself is implemented in Salesforce development console where can be modified and tested. There are also helpful plugins to IDE and without them the development is not really possible. To the most common plugins belong force.com for eclipse and mavensmate that functions independently from IDE. Based on my experience, mavensmate v 0.0.11 beta 6 is sufficient although there are still some deficiencies.
For debugging it is necessary to have a browser with developer tools, but I recommend using plugins. There are two basic plugins for Chrome. The first one “Salesforce Lightning Inspektor” is the official from Salesforce and provides statistics of the application lifecycle. The second one “Lightning Linter Chrome” is not official, but makes debugging easier and directly in development Salesforce console.
Developers, do not be afraid of Lightning, it is a future we cannot avoid and as AURA is an open source it contains more and more improvements. To advice, if you are developing, do not forget to set up Salesforce Debug Mode in Setup—Develop—Lightning Component; otherwise, the code incoming to the browser will be automatically optimized to very unreadable message through the google closure.
The testing part of the Lightning development process checks the knowledge of the development company because there is no testing environment created by Salesforce. What can do the company now? Try to choose:
- throw away the unit tests and focus only on UI testing
- decide for the unit testing and create the environment to ensure the maximum quality
- wait while Salesforce comes with its own testing environment and then start to use Lightning
I would prefer to create own testing environment for the very simple reason. Salesforce is responsible for the cloud operation and extending its options without any operation break. Lightning is on the client side so will Salesforce create the environment for the client’s application?
It sounds so easy, but from the professional point of view we have to answer the following questions:
1., Setting space of components and tests
2., Component synchronization from Salesforce
3., The way of sharing
The whole process is a little bit complicated by UI test automatization (testing UI scripts needs to be saved as well). In case of the component, it is not necessary to use these scripts, as it can be ineffective. But within the application, automatized UI testing can save the time and speed up the process. From the future perspective, there is a big advantage of the testing scripts as, in fact, it is type of documentation in the foreign language that refers to the UI tests and can serve as a reminder.
To make a brief summary, I would like to emphasis that Salesforce offered us a very powerful device for creation of the very effective and attractive user environment. The complication of the design and lack of testing environment support divides the development companies into two groups:
1., companies that knows what to do
2., other companies
It’s up to you how you decide.