The spring’17 is already here and as expected, the release comes with new features added for the Lightning components. Lightning components are the heart and soul of the Lightning experience interface and hence it becomes crucial to make them as robust as possible. In this post I will give you a glance of what spring’17 has in store for the Lightning components.

Write Once, Reuse Everywhere: Support for force:hasRecordId in Communities

Until now, the force:hasRecordId interface was available only for Lightning App Builder and Salesforce1. Spring’17 extends the support of this interface to Communities as well. You no longer have to write expression logic for components that you use in the communities. If you haven’t yet used force:hasRecordId, then it’s one of those powerful interfaces that makes your component context aware by adding the record ID from the component’s page to the component at runtime. So what really happens when you implement this interface ?

It automatically adds an attribute named recordId to your component. This attribute is populated at runtime by the recordId of the record where this component is viewed. If you explicitly add this attribute to your component, it would look something like this.

<aura:component implements="force:hasRecordId,flexipage:availableForAllPageTypes,forceCommunity:availableForAllPageTypes" access="global">

   <aura:handler name="init" value="{!this}" action="{!c.doInit}" />


The ID of the record where this component is viewed at runtime can be accessed in the client side controller of the component as seen below

doInit : function(component, event, helper) {

   var recid = component.get("v.recordId");


   Your Component Logic here


Note: To make your lightning components available for communities, you will still need the forceCommunity:availableForAllPageTypes interface.


Access Lightning Apps in Public Communities

Now we can expose our lightning app to public communities with the ltng:allowGuestAccess interface. Prior to this only logged in community users could view your lightning app. This interface allows even the guest users in the community to access the lightning app. However, note that you can add this interface only on Lightning apps and not on Lightning components.  The interface can be implemented in your Lightning app like this

<aura:application implements="ltng:allowGuestAccess">

/* App logic here */


Caution: Be extremely careful about apps you open for guest access. Apps enabled for guest access bypass the object- and field-level security (FLS) you set for your community’s guest user profile. Lightning components don’t automatically enforce CRUD and FLS when you reference objects or retrieve the objects from an Apex controller. This means that the framework continues to display records and fields for which users don’t have CRUD access and FLS visibility. You must manually enforce CRUD and FLS in your Apex controllers. A mistake in code used in an app enabled for guest access can open your org’s data to the world !

Implement Your Own Rich-Text Editor with lightning:inputRichText (Beta mode)

We now have our native WYSIWYG rich text editor which comes in the form of a component named as lightning:inputRichText . The component is based on the Quill JS library that allows you to add, delete, edit and format rich text content.  Pasting rich content into the editor is supported if the feature is available in the toolbar.

So, let’s see how this actually looks. Simply add the below snippet into a component and that should bring up the editor.

<aura:component implements="force:appHostable">
   <lightning:inputRichText />

The output is as seen below


This release of lightning:inputRichText contains some known limitations.

• The editor doesn’t display correctly in narrow views, typically less than 300 pixels in width.

• The font and size menus aren’t accessible to screen readers and are likely to change in future releases.

• The font and size menus don’t close if you click outside the menus without making a selection. Click the menu again to close it.

Note: The spring’17 release contains a beta version of lightning:inputRichText, which means it’s a high-quality feature with known limitations. lightning:inputRichText isn’t generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. We can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features.

Find Component Markup Errors Faster with Improved Error Messages

The framework now shows useful error messages which can be understood by a novice developer. Earlier the framework used to provide a generic message for any errors in the markup during run-time. This change affects all users of an org and doesn’t depend on the debug mode enabled. This also makes the users to report the IT team with the right error messages.


Host Single-Page Apps Developed with Third-Party Frameworks Using lightning:container (Developer Preview)

You can now incorporate third party apps developed using AngularJS or React into your lightning component using the lightning:container. The container hosts the application within an iframe and can only be used for single page applications.lightning:container has known limitations. You might observe performance and scrolling issues associated with the use of iframes. This component is not designed for the multi-page model, and it doesn’t integrate with browser navigation history. For now, content in lightning:container is being served from the Visualforce domain. lightning:container can’t be used in Lightning pages that aren’t served from the Lightning domain, such as Visualforce pages or Community Builder. These restrictions allow lightning:container to comply with LockerService security, and might change in future releases.