function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Squire Q KershnerSquire Q Kershner 

Lighting Component / Javascript

One of our developers just emailed our team with the following statement. I'm not familiar enough with Lightning Developer to determine if the statement is entirely accurate.

"With our orgs now supporting lightning and hopefully more BU’s getting lightning in the future, we will probably need some custom Lightning pages that need code. The hardest and most time consuming part of lightning apps are UI and UX development. Salesforce has given the Lightning Design System which gives you templates to make your page look native. The problem is that they don’t provide any javascript to make things like tables interactive and user friendly. We would have to develop that code ourselves which pretty much triples the time of the project to get something working just OK. Check out the lightningstrike website link below. The site provides a javascript framework that hooks up with the Lightning Design System. Lots of cool UI that we could easily plug and play into any custom app in the future. This could also allow us to create POC’s much easier and make lightning pages immediately mobile friendly."

Would any of the dev community have opinions about the accuracy of this statement and/or resources that might be applicable to discuss in more detail with our dev-team?
Best Answer chosen by Squire Q Kershner
Alain CabonAlain Cabon
Hi,

The message is globally accurate but there will be many improvements for the standard Lightning components.

The Lighting components are not mature for the lookup and the picklists (dependant picklist and picklist according a recordtype).
Lightning Design System is the graphic charter/design without javascript indeed (CSS).

The main problem is the existing Visualforce pages that have the Classics design by default in LEX (Lightning Experience).
I have adapted VFPages in LEX charter.

The javascript is needed for the dependant picklists for example.

The standard Lightning components are not mature (often beta officially in the documentation) if you compare with the Classics components like <apex:inputfield> / <force:inputfield>.  https://developer.salesforce.com/forums/ForumsMain?id=9060G000000Bj9tQAC

Winter 18: New and Changed Lightning Components. Build user interfaces quickly with a bevy of new components.
https://releasenotes.docs.salesforce.com/en-us/winter18/release-notes/rn_lc_components.htm

Lightning Components Roadmap : lightning:lookup + lightning:picklist : future
https://help.salesforce.com/articleView?id=lightning_components_roadmap.htm&type=0


REAL WORLD:  Salesforce open source (Cumulus)

Often, we don't rewrite the Visualforce pages (VFP/apex) into "native" Lex components (Aura/Javascript) but we simply change their charter like here:

https://github.com/SalesforceFoundation/Cumulus/blob/master/src/pages/CON_ContactMerge.page

<apex:page standardController="Contact" extensions="CON_ContactMerge_CTRL"
title="Merge Contacts" id="contactMergePage" recordSetVar="cons" showHeader="true" sidebar="false"
standardStylesheets="false">
<apex:stylesheet value="{!URLFOR($Resource.SLDS, '/0_12_2/assets/styles/salesforce-lightning-design-system-vf.min.css')}"/>
<div class="slds">

or

<apex:page controller="BDI_DataImport_CTRL" title="NPSP Data Import"
tabStyle="DataImport__c" showHeader="true" sidebar="false" action="{!preload}"
docType="html-5.0" standardStylesheets="false">
<apex:slds />   // replace the need of the css LDS ressource like above.

https://github.com/SalesforceFoundation/Cumulus/blob/master/src/pages/BDI_DataImport.page

.... and you have very verbose pages with a lot of SLDS classes (CSS).

<div class="slds-card">
  <div class="slds-card__header slds-grid">
  <h3 class="slds-text-heading--small slds-has-flexi-truncate">{!$Label.bdiDataImporterTitle}</h3>
  <div class="slds-no-flex">
  <apex:commandButton value="{!$Label.bdiBtnClose}" action="{!close}" immediate="true" styleClass="slds-button slds-button--neutral" />
</div>
</div>

But that is always ... Visualforce pages and not real Lex components (Aura/javascript).

Salesforce promised that the Classics charter of the VFP would be adapted in Lex automatically but we have never seen this result until now.

If the Classics charter was adapted "automatically" for the VFP like for the standard Layout in LEX, we would not have to adapt the VFP charter with all this verbose tags of SLDS. We lose all the concise VPF pages as we love to have with these "fake" LEX pages. 

Cumulus use only one charter for his VFPs (for Classics and LEX) so you see the LDS charter in Classics too.

The principle seems simple but the popup for the LOOKUP will be like in Classics and not the great new lookup component of the standard LEX pages.

Migrating <apex:InputField/> Visualforce Component into Lightning Experience World: LexForce was selected to be presented in the breakout session of Dreamforce 2016.
https://justinyue.wordpress.com/2016/01/23/migrating-visualforce-component-into-lightning-experience-world/
https://github.com/Justin1108/sfdc-lexforce

I had very few things to fix in the sfdc-lexforce for my own needs (one bug and it lacks the combobox, easy to fix).  Everything will be Ok (except the popup for the lookup, the illlusion is quite good nevertheless).

"This could also allow us to create POC’s much easier and make lightning pages immediately mobile friendly.""  : the Responsive web design (RWD) can be done with the standard SLDS library without the need of extra libraries.

https://developer.salesforce.com/blogs/developer-relations/2017/04/mastering-salesforce-lightning-design-system-grids-lightning-layouts.html

I HOPE OTHER DEVELOPERS WILL EXPRESS THEIR POINTS OF VIEW HERE (because I feel lonely for all these fundamental questions around the future of the VFP in SF with LEX and the maturity of the LEX components).

Best regards
Alain

All Answers

Alain CabonAlain Cabon
Hi,

The message is globally accurate but there will be many improvements for the standard Lightning components.

The Lighting components are not mature for the lookup and the picklists (dependant picklist and picklist according a recordtype).
Lightning Design System is the graphic charter/design without javascript indeed (CSS).

The main problem is the existing Visualforce pages that have the Classics design by default in LEX (Lightning Experience).
I have adapted VFPages in LEX charter.

The javascript is needed for the dependant picklists for example.

The standard Lightning components are not mature (often beta officially in the documentation) if you compare with the Classics components like <apex:inputfield> / <force:inputfield>.  https://developer.salesforce.com/forums/ForumsMain?id=9060G000000Bj9tQAC

Winter 18: New and Changed Lightning Components. Build user interfaces quickly with a bevy of new components.
https://releasenotes.docs.salesforce.com/en-us/winter18/release-notes/rn_lc_components.htm

Lightning Components Roadmap : lightning:lookup + lightning:picklist : future
https://help.salesforce.com/articleView?id=lightning_components_roadmap.htm&type=0


REAL WORLD:  Salesforce open source (Cumulus)

Often, we don't rewrite the Visualforce pages (VFP/apex) into "native" Lex components (Aura/Javascript) but we simply change their charter like here:

https://github.com/SalesforceFoundation/Cumulus/blob/master/src/pages/CON_ContactMerge.page

<apex:page standardController="Contact" extensions="CON_ContactMerge_CTRL"
title="Merge Contacts" id="contactMergePage" recordSetVar="cons" showHeader="true" sidebar="false"
standardStylesheets="false">
<apex:stylesheet value="{!URLFOR($Resource.SLDS, '/0_12_2/assets/styles/salesforce-lightning-design-system-vf.min.css')}"/>
<div class="slds">

or

<apex:page controller="BDI_DataImport_CTRL" title="NPSP Data Import"
tabStyle="DataImport__c" showHeader="true" sidebar="false" action="{!preload}"
docType="html-5.0" standardStylesheets="false">
<apex:slds />   // replace the need of the css LDS ressource like above.

https://github.com/SalesforceFoundation/Cumulus/blob/master/src/pages/BDI_DataImport.page

.... and you have very verbose pages with a lot of SLDS classes (CSS).

<div class="slds-card">
  <div class="slds-card__header slds-grid">
  <h3 class="slds-text-heading--small slds-has-flexi-truncate">{!$Label.bdiDataImporterTitle}</h3>
  <div class="slds-no-flex">
  <apex:commandButton value="{!$Label.bdiBtnClose}" action="{!close}" immediate="true" styleClass="slds-button slds-button--neutral" />
</div>
</div>

But that is always ... Visualforce pages and not real Lex components (Aura/javascript).

Salesforce promised that the Classics charter of the VFP would be adapted in Lex automatically but we have never seen this result until now.

If the Classics charter was adapted "automatically" for the VFP like for the standard Layout in LEX, we would not have to adapt the VFP charter with all this verbose tags of SLDS. We lose all the concise VPF pages as we love to have with these "fake" LEX pages. 

Cumulus use only one charter for his VFPs (for Classics and LEX) so you see the LDS charter in Classics too.

The principle seems simple but the popup for the LOOKUP will be like in Classics and not the great new lookup component of the standard LEX pages.

Migrating <apex:InputField/> Visualforce Component into Lightning Experience World: LexForce was selected to be presented in the breakout session of Dreamforce 2016.
https://justinyue.wordpress.com/2016/01/23/migrating-visualforce-component-into-lightning-experience-world/
https://github.com/Justin1108/sfdc-lexforce

I had very few things to fix in the sfdc-lexforce for my own needs (one bug and it lacks the combobox, easy to fix).  Everything will be Ok (except the popup for the lookup, the illlusion is quite good nevertheless).

"This could also allow us to create POC’s much easier and make lightning pages immediately mobile friendly.""  : the Responsive web design (RWD) can be done with the standard SLDS library without the need of extra libraries.

https://developer.salesforce.com/blogs/developer-relations/2017/04/mastering-salesforce-lightning-design-system-grids-lightning-layouts.html

I HOPE OTHER DEVELOPERS WILL EXPRESS THEIR POINTS OF VIEW HERE (because I feel lonely for all these fundamental questions around the future of the VFP in SF with LEX and the maturity of the LEX components).

Best regards
Alain
This was selected as the best answer
Alain CabonAlain Cabon
No news.

I am interested by any feedback about all the drawbacks and problems during the migration towards LEX for my own report.

Regards.
Squire Q KershnerSquire Q Kershner
Wow.  Thank you Alain.
Alain CabonAlain Cabon
Hello,

My response is focused on one particular point: the specific graphical LEX charter but the migration towards LEX has many other problems (javascript buttons, URL hacks,  documents and files, joined reports and other ''lovely" stuff that will not work with LEX).

Fortunately, there is the great free automatic Lightning Experience Readiness Check.

There are many trailhead around Lightning and the migration from the Classics version.

The last interesting superbadge is this superbadge (created yesterday) for a training with many common problems and quizzes.

https://trailhead.salesforce.com/fr/super_badges/superbadge_lex_rollout

Regards
Alain
Alain CabonAlain Cabon
Hi,

I has just passed the superbadge Lightning Experience Rollout Specialist and it is a great superbadge (several sensitive issues needed to be solved, a well thought out,comprehensive badge if you plan to migrate to Lightning) 

https://trailhead-leaderboard-developer-edition.na35.force.com/

I will be keeping an eye on your question until the final solution (closed solved question).

Regards
Alain CabonAlain Cabon
Hi,

I am just back from the Lightning Now Tour in Paris.

https://developer.salesforce.com/events/workshops/lightning-now

Marcus Torres and Samuel Alves Rosa (great expertise) presented some interesting new points for Lightning.

Salesforce promised that the Classics charter of the VFP would be adapted in Lex automatically but we have never seen this result until now.

Style Existing Visualforce Pages with Lightning Experience Stylesheets:

You can control whether a page is styled with the look of Lightning Experience when viewed in Lightning Experience or the Salesforce1 app with the lightningStylesheets attribute.
 
<apex:page lightningStylesheets="true">

This is a beta version of Lightning Experience stylesheets for Visualforce, which means it’s a high-quality feature with known limitations. Lightning Experience stylesheets aren’t generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements.​

https://developer.salesforce.com/docs/atlas.en-us.210.0.pages.meta/pages/vf_dev_best_practices_slds_lightningstylesheets.htm (https://developer.salesforce.com/docs/atlas.en-us.210.0.pages.meta/pages/vf_dev_best_practices_slds_lightningstylesheets.htm?search_text=lightning)