One of the biggest announcements from Dreamforce '15 was the new Lightning user interface. For us developers, the part that would be of most interest to us is Lightning Framework – the new component-based Javascript Front-end web framework for Salesforce.com. From going through the Developer's Guide for the Lightning Components, here are my first thoughts and some gotchas I found.
The Lightning Components is intended to allow developing responsive-design single-page app. This should allow the developers to develop not only a Salesforce app that is more responsive than with Visualforce, but it should also allow us build one app that would optimize based on the client, instead of building separate app for Desktop and Mobile devices.
In terms of the structure, I found it to be quite similar MV*-based front-end frameworks such as AngularJS, Backbone.js or Ionic Framework, and if you are familiar with any of those frameworks, you shouldn't have much difficulty with it. The basic structure is that you create an app, which consists of one or more components with each component representing a section of the page. Each component then can have its own stylesheet, controller/helper scripts, and events.
Some of the main benefits I see is that because it is based on the Javascript, it should make it easier to implement custom Javascript components, such as auto-complete input box. If you have had experience of taking over the input field with custom code in Visualforce page, you know how nightmarish of task it can become, dealing with Visualforce-specific convention regarding IDs and trying to resolve conflict between Visualforce tag and your Javascript code. Also, the UI testing and testing automation should be easier with this framework as you don't have to deal with auto-generated mark-ups from compiled Visualforce code and aforementioned ID conventions. I would also like to mention Live Preview support in regards to testing, which you can open from Developer Console. Finally, this will make managing your CSS stylesheet much easier as you have a separate CSS file associated with each component, instead of having to deal with either static resources or embedded CSS.
As for drawbacks, I did find a few potential issues. One such issue may be that you have to customize the look-and-feel of every component with your own stylesheet. One advantage of Visualforce is that it gives you a consistent look-and-feel to the Salesforce platform by default, which is lost with custom stylesheet. Another issue I found was the file structure. With the component-based structure, it appears to have completely different file-system structure to the rest of the Apex and Visualforce code directory structure we are familiar with. As far as I know, you can only edit Lightning Components code from Developer Console, but I would assume it will become available in Force.com IDE and Mavensmate, and I wonder how those IDE/editros will be able to handle this rather diverging structure.
Finally, I would like to close this post with some gotchas I found while going through the Developer's Guide:
- You can’t use Force.com Canvas apps in Salesforce1 if you enable Lightning components.
- I think this may be the biggest issue for people looking into enabling Lightning components.
- In order to use Lightning Components, you need to register separate namespace for it.
- Some HTML tags are not supported with Lightning Components.
- Please see https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/ref_supported_html_tags.htm for the list of the supported components.
- You need to create a custom tab in order to enable your component in the Salesforce1 Navigation menu.
- Also, accessing your Lightning Component from the full Salesforce site is not supported - another major issue that I would think would be resolved before going into GA.
