Learn What’s New in Lightning Web Components and Visualforce
After completing this unit, you’ll be able to:
- Learn about reactive fields in Lightning Web Components.
- Use Lightning message service to communicate across the DOM.
- Check user’s permissions for Lightning Web Components.
- Prepare to remove instance names from Visualforce URLs.
The @track Decorator Is No Longer Required for Lightning Web Components
Previously, it was difficult for developers to know which Lightning web component fields to decorate with
@track. When a field’s value changed, developers couldn’t easily predict when the component would re-render and display the new value.
Since Spring ’20, there’s no more guessing about whether to use
@track to make a field reactive. All fields in a Lightning web component class are reactive. If a field’s value changes, and the field is used in a template or in a getter of a property that’s used in a template, the component re-renders and displays the new value.
How does it work?
Since all fields in a Lightning web component class are reactive, the framework observes changes to a field’s value, rerenders the component, and displays the new value. All expressions in the component are also evaluated.
Before Spring ’20, to make a field reactive, you had to decorate it with
@track. This is still supported if you happen to see this approach used in older code samples.
Additionally, there is still one use case for
@track. When a field contains an object or an array, there’s a limit to the depth of changes that are tracked. To tell the framework to observe changes to the properties of an object or to the elements of an array, decorate the field with
@track, the framework observes changes that assign a new value to a field. If the new value is not
=== to the previous value, the component re-renders.
For additional explanation and sample code, see the Salesforce Spring '20 Release Notes: The @track Decorator Is No Longer Required for Lightning Web Components.
Communicate Across Salesforce UI Technologies with Lightning Message Service
Use Lightning message service to communicate across the DOM—between Visualforce pages, Aura components, and Lightning web components, including components in a utility bar. You can use it to communicate between components within a single Lightning page or across multiple pages. If you’re switching from Salesforce Classic to Lightning Experience, you can now build Lightning web components that can communicate with existing Visualforce pages and Aura components. You can also use Lightning message service to communicate with softphones via Open CTI.
How does it work?
Components and pages communicate over Lightning message channels. For example, a Visualforce page can subscribe to the same message channel on which a Lightning web component publishes.
If you worked with Lightning message service in beta, note the scope parameter has changed for the GA release. The scope parameter defines where subscribing components receive messages in your application.
In the beta release, the
subscribe() method included a scope parameter, with a single default value of the entire application. With GA in Summer ‘20, the Lightning message service now lets you limit scope to the active area only (default) or include the entire application.
To specify active scope, you don’t need to include the scope parameter, since it’s the default behavior. To specify scope for the entire application, continue to use the optional scope parameter with the imported value of
When using the active scope, a message channel is limited to communication between components in an active navigation tab, an active navigation item, or a utility item. Utility items are always active. A navigation tab or item is active when it’s selected. Navigation tabs and items include:
- Standard navigation tabs
- Console navigation workspace tabs
- Console navigation subtabs
- Console navigation items
For additional explanation and sample code, see the Component Reference: lightning/messageService.
Check User Permissions for Lightning Web Components
Permissions are a standard way to control access and behavior in a Salesforce org. When you develop Lightning web components you can customize a component’s behavior based on whether the current user has a specific permission.
How does it work?
To check whether a user has a permission, import Salesforce permissions from the
@salesforce/customPermission scoped modules and evaluate whether it’s true or undefined. Then if the user has the permission, the component can take a specific action.
Custom permissions can include a namespace. Orgs use namespaces as unique identifiers for their own customization and packages. If the custom permission was installed from a managed package, prepend the namespace followed by
__ to the permission name.
Standard Permission Example:
import hasPermission from '@salesforce/userPermission/StandardPermissionName';
Custom Permission Examples:
import hasPermission from '@salesforce/customPermission/CustomPermissionName';
import hasPermission from '@salesforce/customPermission/namespace__CustomPermissionName';
The name of the static reference is your choice. These examples chose the format
hasPermission to indicate that the reference contains a Boolean.
Shorten Your Visualforce URLs
We’re removing the instance names from Visualforce and other URLs through a release update. An instance name identifies where your Salesforce org is hosted, such as na44. Removing the instance name from URLs makes domains shorter and easier for users to remember.
How does it work?
This update applies to orgs that have a deployed My Domain. For example,
mydomain--c.visual.force.com without the instance na44 in the URL. When we remove the instance name from the URL, the hostname changes. After this update is activated, URLs that include the instance name, such as a bookmark, automatically redirect to the new hostname.
Some examples of hostname changes include:
Planning for this update
This update was first made available in Spring ’18 and is enabled automatically in sandbox orgs when they are created or refreshed. Salesforce planned to enforce this update in all orgs in Summer '21, however, this update is now postponed until Summer '22. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab.
For more information on hostname changes and how to plan for and test this update, see Stabilize URLs for Visualforce, Experience Builder, Site.com Studio, and Content Files (Previously Released Update)