Lightning has been the central focus for Salesforce for quite sometime now. Customers, partners and developers seem to be equally delighted about the refreshing experience brought in by Lightning. However, when it comes to implementing a project wherein you need to migrate an org from classic to lightning, folks are often in a dilemma on the approach to take. A very common example that I can take is if you ask a developer to migrate a VF page to Lightning, he/she would be stumbled with the following questions lingering on their mind
- Should I rewrite the VF page entirely ?
- Should I just modify the page to incorporate the Lightning Design System ?
- Should I create a new Lightning component ?
- Should I just embed a Lightning component inside the current VF page ?
So, let’s clear that air of confusion in this post. Migration to lightning has two different paths. Before we talk in detail about each, let’s understand a little more about the Lightning Design System and the Lightning Experience.
Lightning Design System
This an enterprise CSS framework built by Salesforce with styles and designs that have been incorporated into the standard theme of Salesforce Lightning experience. The framework has styles and designs that suit all type of components you would typically use in building pages/components in Salesforce. To use the framework, one just has to go to this website, download the framework(applicable only if you use the Lightning Design System in a VF page) and start referring the style sheet classes in your page/component. The good news is that this is available as an open source project in github, which means that you can directly provide feedback on the issues in the framework and also help to make the framework better. The catch here is that the framework can be used with equal ease in both. visual force pages and lightning components, though the approach to use differs a little.
Lightning experience is the re-designed platform of Salesforce. It has been redesigned on both fronts, architecture and UI/UX. The approach to develop new stuffs for Lightning experience has totally changed now and lightning components are the way to go when you talk about building new features intended for Lightning experience. This means that you will be developing fresh new lightning components from the ground. The components that you develop can be embedded within a visual force page as well.
Now, that we have an idea about Lightning, let’s talk in detail about the approaches available when you talk about migrating to Lightning.
Path 1 : Convert existing VF pages using Lightning Design System (VF Pages + LDS)
This approach basically means that you will just be making minor tweaks to your existing visual force pages using the lightning design system and using them in the lightning environment. Yes, lightning indeed supports visual force pages. However, this is not really recommended, because then you won’t be leveraging the benefits of the Lightning architecture. This approach only means that you would only change the look and feel of the visual force pages to match it with lightning experience. The approach has it’s own flaws like if you have built-in standard components in your visual force pages, they won’t be rendered well in the Lightning experience. Though this is the easiest way to migrate to lightning, it has a huge number of limitations and definitely not the recommended approach to migrate to lightning.
Steps for this approach
- Modify the existing VF page to be enabled in Lightning
- Use the Lightning Desgin System in your existing VF page to match the look and feel with that of lightning experience.
- Deploy the page to be used in Lightning Experience
A few links to help you with this approach
Path 2 : Scrap the existing VF pages and create new Lightning Components
This means that you will completely discontinue the existing visual pages in your org and create corresponding new lightning components to mimic their functionality in lightning experience. This approach requires a lot of leg work, but is highly recommended because you will be using the revamped lightning architecture in this approach. You will be using a client-centric architecture which will make your application faster and responsive. Organizations that have a huge number of customized visual force pages will need a lot of time to develop fresh new components to replace the older visual force pages, because the methodology to develop lightning components differs largely from visual force development. However, later down the line, life will be easier with this approach, as you can easily incorporate the latest advancements in lightning that comes out with each release.
Steps for this approach
- Scrap the existing VF page
- Develop a new lightning component(s) using the Lightning Design System which should perform the functionality of the VF page that was scrapped
- Deploy the component to be used in Lightning Experience.
A few blogs which will help you with Lightning Component development
Now, let’s again walk through the questions in the beginning of this post !
Should I rewrite the VF page entirely ?
- Path 1 : No, you just have to tweak the VF pages to incorporate the lightning design system.
- Path 2 : You will no longer be using the VF pages. You will scrap them entirely and build lightning components to replace the VF pages.
Should I just modify the page to incorporate the Lightning Design System ?
- Path 1 : Yes
- Path 2 : Since you will be building new lightning components, you will be incorporating the LDS in your components.
Should I create a new Lightning component ?
- Path 1 : Not needed. You can continue to use the older VF pages by tweaking them.
- Path 2 : Yes
Should I just embed a Lightning component inside the current VF page ?
- This is totally upon you. If you want to develop a fresh new components and embed it inside a VF page, you can definitely do so. However, personally I would prefer to embed a component within another lightning component itself and not a VF page.