Maintain Your JavaScript Developer I Certification for Summer ’23

Learning Objectives

After completing this unit, you’ll be able to:

• Synchronize component data without a page refresh using RefreshView API.
  
• Use Lightning Web Security for Lightning Web components and Aura components.
  
• Use Lightning Web Security by default in new Salesforce orgs.
  
• Query DOM elements with refs.
  
• Use the improved conditional directives.
  
• Create overlays with the new modal component.
  

Maintain Your Certification

If you hold the Salesforce JavaScript Developer I credential, keep in mind that you need to complete this module by the due date to maintain your certification. Another important part of maintaining your credential is ensuring your Trailhead and Webassessor accounts are linked.

Interested in learning more about getting certified? Check out the Salesforce JavaScript Developer I credential.

Although anyone can earn this badge, this module is designed for Salesforce Certified JavaScript Developer I developers. This level of knowledge and experience is assumed in the instruction provided. 

Protect the Integrity of Your Certification

The quality of our certification exams and the value our credentials provide are our highest priority. Protecting the security and confidentiality of our exams is essential to providing our customers with credentials that are respected and industry-leading.

As a participant of the Salesforce Certification Program, you’re required to accept the terms of the Salesforce Credential and Certification Program Agreement. Please review the Salesforce certification exam-taking policies in the Salesforce Credential and Certification Program Agreement and Code of Conduct Salesforce Help article for more details.

Salesforce introduced a ton of great feature enhancements over the past several releases. Let’s take a look at some of the more important ones for this release.

Synchronize Component Data Without a Page Refresh Using RefreshView API

Whether user-driven or app-invoked, the ability to synchronize data without reloading an entire page is a key user experience requirement. The new lightning/refresh module and RefreshView API provide a standard way to refresh component data in Lightning web components (LWC) and Aura components. Previously, LWC lacked a data refresh API and could only refresh using an Aura wrapper and the legacy force:refreshView, which doesn’t meet the requirements of modern web development. RefreshView API’s detailed control of refresh scope lets developers create refined user experiences while maintaining backward compatibility. This feature, now generally available, includes some changes since the last release.

Where: This change applies to Lightning Experience in Enterprise, Unlimited, and Developer editions. Lightning Web Security (LWS) must be enabled in the Salesforce org.

How: RefreshView API updates the data for a specific hierarchy of components, known as a view, without reloading an entire page. This refresh ensures complete synchronization with data externally sourced by components that subscribe to the refresh event in that view. RefreshView API supports refreshes that are triggered by end users or web components. RefreshView API provides a standard mechanism for data refresh experiences, allowing flexible control of refresh scopes.

RefreshView API can refresh data for Salesforce Platform containers and custom LWC and Aura components. The base Lightning Aura components currently don’t support RefreshView API.

Lightning Locker doesn’t support RefreshView API.

Use Lightning Web Security for Lightning Web Components and Aura Components

Lightning Web Security (LWS) for Aura components is now generally available (GA). Salesforce continues the gradual rollout of the LWS architecture, which was announced as generally available for Lightning web components in Spring ’22. 

Where: This change applies to Lightning Experience in all editions. LWS affects Lightning web components and Aura components in Aura-based Experience Cloud sites. It doesn’t affect LWR-based Experience Cloud sites, which use their own instance of LWS. New orgs, scratch orgs, and sandbox orgs have LWS for Lightning web components and Aura components enabled by default, beginning with the Spring ’23 release.

Why: Lightning Locker has been the default security architecture for Lightning components. LWS started to replace Lightning Locker for Lightning web components in Spring ’22. Now, LWS works for Aura components, too.

How: LWS for Aura is controlled by the Use Lightning Web Security for Lightning web components and Aura components setting in Session Settings in Setup.

The Use Lightning Web Security for Lightning web components and Aura components setting applies to all existing and new custom Lightning web components and Aura components.

The primary test method is the manual validation of your components in a sandbox. We recommend that you set up two identical sandboxes. To compare your components’ behavior with LWS versus Lightning Locker, enable the LWS setting in Setup for one of the sandboxes. To compare behaviors if you have only one sandbox, enable or disable the LWS setting in Setup for each comparison.

If you plan to deploy existing or packaged Lightning web components or Aura components to production, test first in a sandbox with LWS enabled.

If your org had the “Use Lightning Web Security for Lightning web components” setting enabled before Spring ’23 and your org contains custom Aura components, LWS remains enabled but affects only your Lightning web components. Your org was excluded from LWS for Aura (beta) and is still excluded now that the feature is GA so that it doesn’t affect your Aura components in Summer ’23. The goal of our gradual LWS rollout is to start with orgs that aren’t expected to be affected by LWS and to eventually enable LWS for all orgs.

The exclusion of some orgs from LWS for Aura applies only to production orgs. LWS for Aura components is enabled in Summer ’23 sandboxes so that you can start testing your Aura components.

This table summarizes whether LWS for LWC and LWS for Aura features are in effect in a Summer ’23 production org if LWS was previously enabled in Winter ’23 and Spring ’23.

If LWS wasn’t enabled in a production org in Winter ’23 and Spring ’23, when your admin enables it in Summer ’23, LWS for LWC and LWS for Aura are both in effect.

Use Lightning Web Security by Default on New Salesforce Orgs

The Use Lightning Web Security for Lightning web components setting is enabled by default in new Salesforce orgs. This enablement continues the gradual rollout of the new Lightning Web Security architecture announced in Spring ’22.

Where: This change applies to new Salesforce orgs that use Lightning Experience in all editions. The Lightning Web Security setting affects Lightning web components that are used in Aura-based Experience Cloud sites. It doesn’t affect LWR-based Experience Cloud sites. Scratch orgs also have Lightning Web Security enabled by default.

How: The setting Use Lightning Web Security for Lightning web components and Aura components is located in Session Settings in Setup. You can return the org to use Lightning Locker for Lightning web components by deselecting the setting. If your org has no Lightning components, there's no reason to return to Lightning Locker. If your org has only Lightning web components, consider returning to Lightning Locker only if components exhibit issues with LWS enabled.

If you plan to populate the new org with pre-existing or packaged Lightning web components, be sure to test first in a sandbox environment with LWS enabled. If your Lightning web components aren’t working properly with LWS and you can’t solve the issue using these resource links, open a Support case.

Use the lockerServiceNext boolean in scratch org definition files to enable and disable LWS in your scratch orgs. For example, add these lines to the definition file to disable LWS in your scratch org.

"settings": {
     "securitySettings": {
         "sessionSettings": {
            "lockerServiceNext": false
           }
      }
}

Query DOM Elements with Refs

Now you can use refs to access elements in shadow DOM and light DOM. Refs locate DOM elements without a selector and only query elements contained in a specified template. Previously, you could only use querySelector() to locate specific DOM elements.

Where: This change applies to Lightning Experience, Salesforce Classic, and all versions of the mobile app in all editions.

How: First, add the lwc:ref directive to your element and assign it a value. To call that reference, use this.refs. In this example, the <div> element has the directive lwc:ref="myDiv", which this.refs references to access the <div> at runtime.

<template>
    <div lwc:ref="myDiv"></div>
</template>




export default class extends LightningElement {
  renderedCallback() {
    console.log(this.refs.myDiv);
  }
}

If you call this.refs for a nonexistent ref, it returns undefined. If the template contains duplicate lwc:ref directives, this.refs references the last directive. For a component with more than one template, this.refs refers to the most recently rendered template.

Use the Improved Conditional Directives

The lwc:if, lwc:elseif, and lwc:else conditional directives supersede the legacy if:true and if:false directives.

Where: This change applies to custom Lightning web components in Lightning Experience, Experience Builder sites, and all versions of the Salesforce mobile app. This change also applies to Lightning web components in Open Source.

How: With the lwc:if, lwc:elseif, and lwc:else conditional directives, the property getters are accessed only one time per instance of the directive.

<!-- conditionalExample.html -->
<template>
   <template lwc:if={isTemplateOne}>
        This is template one.
   </template>
   <template lwc:else>
       This is template two.
</template>
</template>

Both lwc:elseif and lwc:else must be immediately preceded by a sibling lwc:if or lwc:elseif.

Pass in an expression to lwc:if and lwc:elseif, but not to lwc:else.

If expression1 returns a truthy, none of the other property getters are accessed.

<!-- example.html -->
<template>
    <template lwc:if={expression1}>
        Statement 1
    </template>
    <template lwc:elseif={expression2}>
        Statement 2
    </template>
    <template lwc:else>
        Statement 3
    </template>
</template>

Previously, chaining if:true and if:false blocks introduced performance cost and resulted in the property getters getting called multiple times.

<!-- legacyConditional.html -->
<template>
    <!---Replace if:true with lwc:if-->
    <template if:true={isTemplateOne}>
        This is template one.
    </template>
    <!-- Replace if:false with lwc:else -->
    <template if:false={isTemplateOne}>
        This is template two.
    </template>
</template>

IMPORTANT The legacy if:true and if:false directives are no longer recommended as we intend to deprecate and remove these directives in the future. We recommend that you replace their usage with the new conditional directives to future-proof your code.

Consider these guidelines when working with the lwc:if, lwc:elseif, and lwc:else conditional directives.

• Use the conditional directives on nested <template> tags, <div> tags, or other HTML elements, and on your custom components tags like <c-custom-cmp>.
  
• You can’t precede lwc:elseif or lwc:else with text or another element. Whitespace is ignored between the tags when the whitespace is a sibling of the conditional directive. For example, you can’t have a <div> tag that comes after lwc:if and before lwc:else.
  
• Complex expressions like !condition or object?.property?.condition aren’t supported. To evaluate complex expressions, use a getter in your JavaScript class.
  

Create Overlays with the New Modal Component

Use modals to interrupt a user’s workflow and draw attention to an important message. A modal, which displays the message on top of the current app window, requires a user to interact with it to regain control over the app.

Where: This feature is available for Lightning Experience in all editions.

How: To create a modal component, import LightningModal from lightning/modal in your JavaScript file. Then, create a component class that extends LightningModal.

/* c/myModal.js */
import { api } from 'lwc';
import LightningModal from 'lightning/modal';
export default class MyModal extends LightningModal {
    handleOkay() {
        this.close('okay');
   }
}

This component doesn’t use a lightning-modal tag. Instead, the modal’s HTML template uses helper lightning-modal-* components to make the modal’s header, footer, and body. The lightning-modal-body component is required, and the others are optional.

<!-- c/myModal.html -->
<template>
    <lightning-modal-header label="My Modal Heading"></lightning-modal-header>
 <lightning-modal-body>This is the modal’s contents.</lightning-modal-body>
  <lightning-modal-footer>
      <lightning-button label="OK" onclick={handleOkay}></lightning-button>
  </lightning-modal-footer>
</template>

Resources

• Salesforce Help: Synchronize Component Data Without a Page Refresh Using RefreshView API
• Lightning Web Components Developer Guide: Refresh Component Data with RefreshView API
• Lightning Web Components Developer Guide: Lightning Web Security
• Salesforce Help: Use Lightning Web Security for Lightning Web Components and Aura Components
• Salesforce Help: Use Lightning Web Security by Default in New Salesforce Orgs
• Salesforce Help: Query DOM Elements with Refs
• Lightning Web Components Developer Guide: Access Elements the Component Owns
• Salesforce Help: Use the Improved Conditional Directives
• Lightning Web Components Open Source Developer Guide: Render DOM Elements Conditionally 
• Salesforce Help: Create Overlays with the New Modal Component
• Salesforce Developer Guide: Component Library