The last month or two of my life have been very very busy, but I still managed to spend a significant amount of time in the Salesforce world. I spent a decent amount of time getting prepared for the Lightning Experience from a technical perspective of understanding functionality, capabilities, etc., and then from a community perspective by planning and hosting our DUG’s viewing party. I also made it to Dreamforce and was able to attend many developer technical sessions, including many related to the Lightning Experience. My two biggest takeaways from the past couple of months in the Salesforce world are, (1) The Lightning Experience is huge and will change the way Salesforce developers do their jobs, and (2) Trailhead is an amazing learning platform with unlimited potential that makes it easier for developers to come up to speed on the latest and greatest. In this post I join the two by reviewing the Developer Trail – Lightning Experience on Trailhead along with my thoughts on some of the content of the units and features of the Lightning Experience.
My initial foray into the Lightning Experience + Trailhead were the Sales Rep Trail – Using Lightning Experience, Admin Trail – Starting With Lightning Experience, and Admin Trail – Migrating to Lightning Experience. A few of my co-workers and I completed them on the day of the Meet the New Salesforce global viewing (btw, they’ve been added to since). All of those trails are very useful and help form a good foundation and understanding of what can be achieved with and how users use and administer the Lightning Experience, but the Developer Trail is essential for developers.
Lightning Experience Basics
The Developer Trail begins with the Lightning Experience Basics module which gives a good introduction to the basics of the Lightning Experience. It includes an overview of the key pieces of the Lightning Experience and what is different and how it relates and interacts with Salesforce Classic. It also contains extremely detailed information to help guide you to making the correct decision on whether enabling the Lightning Experience or keeping with Salesforce Classic for the time being is the right move. An enablement pack that includes sample documents is provided to help you make the decision. The trail shows you how to enable the Lightning Experience and roll it out to your org. What I found to be the added bonus of extra usefulness in this trail was all of the information about how to make the decision of whether or not to make the switch over. The trail could have just presented the different technical pieces of the Lightning Experience and some differences with Salesforce Classic and left it at that, but instead a whole lot of extra information and guidance was provided. It is content like that, that helps to make Trailhead very useful.
Lightning Experience Development
This module begins with a unit on User Interface Considerations which states how Visualforce page-centric applications differ from Lightning Experience app-centric applications. There is a very useful table that details technology recommendations for different scenarios that will help you to decide if you should be using Lightning Components, Visualforce, third-party JS frameworks (e.g., angular), or some combination of them.
The unit Using Visualforce in Lightning Experience is very useful because it outlines what works, what works but may need some work to get it to work, and what doesn’t work. The what doesn’t work is especially helpful for those wanting to make sure they’ve covered everything in planning to migrate existing code. It states that stability was favored for the initial release over trying to adapt all of the standard VF components to the Lightning Experience. This makes sense, and one thing that is stated throughout all of the units is that a ton of work is being done and will continue to be done. It is my hope that inputFields do get converted or some equivalent Lightning Component that has their capabilities is provided so that we can continue to easily make use of features that save a ton of development time and money like field sets with inputFields, the functionality of lookups, date fields, and all of the currency and locale functionality. I will note that it is simple enough to style an inputField with the SLDS (covered later in this post), but the useful functionality of the inputField (lookups, etc.) is not yet there.
Visualforce & Lightning Experience
The module starts of with the unit Using Visualforce in Lightning Experience which shows the different places that Visualforce pages can be used in the Lightning Experience, including as a component in Lightning App Builder.
Since the Lightning Experience is more of a single page app you cannot directly navigate to your Visualforce page (e.g., /apex/yourPage) to develop and test it. However, a very useful bookmarklet is supplied in the Developing Visualforce Pages for Lightning Experience that will allow you to easily navigate to Visualforce pages within the Lightning Experience.
The unit Sharing Visualforce Pages Between Classic and Lightning Experience discusses techniques for determining whether a Visualforce page is running in the Lightning Experience or Salesforce Classic. The important takeaway here is that the detection method is to check for the existence of the sforce.one object, however that is also present in the Salesforce1 app context, so, technically if you had behavior you wanted different in Salesforce1 app vs. Lightning Experience this wouldn’t work. The unit also, safe harbor, states that better ways of context detection are being worked on, so for now I’d abstract it into a function and reference the function, so that later only the function implementation needs to be changed. Note that the detection at this time is client side. A server side detection mechanism is given in the unit, but it only returns a user preference which may not necessarily be the actual context. For more on the features to avoid in The Lightning Experience, check out the Knowing Which Features to Avoid in Lightning Experience unit which is very good single reference page of gotchas.
The Managing Navigation unit describes the ways to navigate in Salesforce Classic vs. Lightning Experience. The biggest takeaway here is to make sure that you are not manually building a record URL out of a String (e.g., ‘/’ + sfId + ‘/e’). You should be (should have always been) using $URLFOR in VF or StandardController actions in Apex. If you followed those best practices you should be fine.
When the Lightning Components Trailhead module first came out last Spring, I reviewed it in this previous post, so I won’t go into much detail in this post. It is an excellent module that provides a great introduction and broad overview of the Lightning Component framework, along with best practice and useful debugging tips. One thing worth noting is that since that review, more Lightning Component development content has been added to Trailhead in the form of projects, which give you hands on experience with app building through guided step-by-step directions.
Lightning Design System
The Lightning Design System module begins with a quick overview of the Salesforce Lightning Design System (SLDS), including where it can be used, which is basically everywhere since it is a CSS framework. It goes on to give a quick intro to the Block Element Modifier (BEM) CSS naming convention. What I like about using that convention is that it makes it easier to remember which classes to use. With some experience, you can reason about what is the proper css class name to use. One of the other key aspects of the SLDS is that it supports tokens and CSS preprocessing so that developers can customize and stay in line when Salesforce makes updates.
The Understanding the Grid System unit gives a quick look at the layout system provided in the SLDS. It is somewhat similar to the grid system of bootstrap and also has a mobile first approach for breakpoint specification. I like that the system allows you to specify columns as ratios of 2,3,4,5,6, and 12. For example, you could have column one be 2 of 5, column two be 1 of 5, and column 3 be 2 of 5.
The unit Working with Salesforce Data shows how Remote Objects can be used with a Data Table and Form components to make use of Salesforce data. One thing to note is that the components do not contain any functionality. You have to write and hookup all of the JS yourself. There is an sldsx github repo that contains more coarse grained SLDS components with some functionality and, of course, there are Lightning Components that can be styled with SLDS.
The module finishes up with a tutorial that ties it all together, Laying out a Record Home Page and Using Advanced Components. It gives you an overall look at may different options and how you would go about attacking the development of a page. I specifically like how it shows a process for starting off with a skeleton structure and then adding in until completed. I’ve found this approach to be very useful.
The trail Developer Trail – Lightning Experience is a must for Salesforce developers from part time novice to full time advanced. Parts of the trail are geared more towards the full time (e.g., SLDS), but all of the content is useful. I particularly like that it is acknowledged that the Lightning Experience is a work in progress and many significant updates will be coming soon. The sections that give guidance on how to decide when it is appropriate to make the switchover are extremely valuable. I am looking forward to more units and modules or updates to existing ones as more functionality is added.