Maintain Your JavaScript Developer I Certification for Summer ’24

Learning Objectives

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

Dynamically import and instantiate Lightning Web components.
Navigate to a URL-addressable Lightning Web component.
Prepare for SLDS architecture updates.
Prepare for native shadow DOM updates to Lightning base components.
Review code using class and style attributes for extra white spaces.

Maintain Your Certification

If you hold the 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 JavaScript Developer I credential.

While anyone can earn this badge, this module is designed for those who hold the JavaScript Developer I certification.

Protect the Integrity of Your Certification

The quality of our certification exams and the value that 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 Trailhead Help article for more details.

Salesforce introduced great feature enhancements over the past year. Let’s take a look at some of the more important ones.

Dynamically Import and Instantiate Lightning Web Components

Dynamic component creation can help you avoid loading large modules that you don’t need for all use cases. Also, you can create a component instance when the underlying component constructor isn’t known until run time. Dynamic import is a convenient solution to make a component more customizable. However, it isn’t always the best solution because of the run-time performance overhead it introduces, so don’t overuse it.

Where: This change applies to Lightning Experience in Enterprise, Unlimited, and Developer editions.

How: To dynamically import and instantiate Lightning web components, enable Lightning Web Security, and set the apiVersion property in the component configuration file to 55.0 or later.

For details on how to instantiate a component dynamically, see the Lightning Web Components Developer Guide.

LWR Sites for Experience Cloud supports only statically analyzable dynamic imports. For this use case, import("c/analyzable") works, but import("c/" + "analyzable") doesn’t work because it isn’t statically analyzable.

Navigate to a URL-Addressable Lightning Web Component

Make your component available via a URL using the lightning__UrlAddressabletarget. To create a URL addressable component, you no longer have to embed your Lightning web component in an Aura component. The ability to deep link to specific components, bookmark views of the application for review at a later time, and improved navigation are ways this enhancement provides more flexibility and control to developers.

Where: This change applies to custom Lightning web components in Lightning Experience and all versions of the Salesforce mobile app. This change also applies to Lightning console apps in Enterprise, Performance, Unlimited, and Developer editions. This change isn’t available in Experience Builder sites because it interferes with custom domain and CDN support.

How: To generate a URL for your Lightning web component and make it available via a URL, include the lightning__UrlAddressable target in your component’s .js-meta.xml configuration file. Set the <isExposed>tag totrue. The <apiVersion>tag has no impact on this feature and can be set to an earlier or later version.

<!-- myComponent.js-meta.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>59.0</apiVersion>
    <isExposed>true</isExposed>
    <targets>
        <target>lightning__UrlAddressable</target>
    </targets>
</LightningComponentBundle>

To navigate to the custom component, use the lightning/navigation module with the standard__component page reference type.

// navToComponentWithState.js
import { LightningElement } from 'lwc';
import { NavigationMixin } from 'lightning/navigation';


export default class NavToComponentWithState extends NavigationMixin(LightningElement) {
  navigateToComponent() {
    this[NavigationMixin.Navigate]({
      // Pass in pageReference
      type: 'standard__component',
      attributes: {
        componentName: 'c__myComponent',
      },
      state: {
        c__propertyValue: '2000',
      },
    });
  }
}

The standard__component page reference type has this attribute.

componentName—The Lightning web component name in the format namespace__componentName.

You can pass any key and value in thestate object. The key must include a namespace, and the value must be a string. If you don’t have a registered namespace, add the default c__ namespace.

In your URL addressable component, myComponent, use a getter to return the property value from thestate object.

// myComponent.js
import { LightningElement, wire, api } from 'lwc';
import { CurrentPageReference } from 'lightning/navigation';


export default class MyComponent extends LightningElement {
    @wire(CurrentPageReference)
    currentPageRef;


    @api propertyValue;


    get propertyValue() {
        return this.currentPageRef.state.c__propertyValue;
    }
}

A component with thelightning__UrlAddressable target has a URL with the format /lightning/cmp/c__MyComponent?c__mystate=value.

Prepare for SLDS Architecture Updates

Starting with the Summer ’24 Release, Salesforce is modifying the internal implementations of our Lightning components, Salesforce Lightning Design System (SLDS) styles, and custom properties to support future UI changes. At Salesforce, we’re constantly improving our UI architecture and planning for the future. For this reason, Salesforce may change the internal implementation of UI components.

Confirm Your Components Use Supported Design System Customizations

If you customize your components or sites using supported techniques, we expect the SLDS architecture updates to have little to no impact on your customizations. However, if your components use unsupported customizations, we recommend that you update them to use supported techniques to prevent visual regressions.

Where: These changes apply to Lightning Experience, Experience Cloud sites, and all versions of the Salesforce mobile app in all editions.

We’re changing the internals of some UI components, which can change the rendered DOM. Don’t modify the DOM elements of Salesforce components via CSS or JavaScript or target SLDS classes in unit tests. See Salesforce Component Internals Are Protected.

If you customize Lightning pages or Experience Cloud sites by targeting Salesforce components and CSS styles that change with the architecture updates, some visual regressions are possible. Visual regressions can range from a UI component displaying a slightly different color to layout changes in your UI.

How: For information about supported and unsupported customization techniques, and how to update your site, see the SLDS Architecture Updates FAQ.

Prepare Your LWR and Aura Sites

We expect the SLDS architecture updates to have little to no impact on your site customizations. However, if your site customizes Salesforce components by overriding their CSS, we recommend that you instead use supported techniques. Otherwise, your site can’t adopt future product innovations of the UI without experiencing visual regressions.

Where: This change applies to Aura and LWR sites accessed through Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.

Prepare for Native Shadow DOM Updates to Lightning Base Components

Salesforce continuously works to align base Lightning components with web standards. The newest effort is part of our process for Lightning Web Components to support native shadow DOM in a future release (safe harbor).

Salesforce is preparing base Lightning components to adopt native shadow DOM to enhance performance and comply with Web Components standards. These updates change the internal DOM structure. Ensure that your tests don’t rely on the previous internal structure of these components. From Spring ’23 to Summer ’24 release dates, 62 components were adapted to prepare for native shadow DOM.

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

In Summer ’24, these additional components were adapted to prepare for native shadow DOM.

lightning-button
lightning-file-upload
lightning-formatted-name
lightning-formatted-number
lightning-navigation
lightning-progress-bar
lightning-progress-ring
lightning-select
lightning-textarea

Salesforce documented that the internal component structure is protected. Salesforce may at any time redesign the internals of our components to improve performance, enhance functionality, and support accessibility. See Anti-Patterns for Styling Components.

Important: If your tests rely on this protected internal DOM structure, rewrite your tests as soon as possible.

To ensure that your tests are ready for the internal DOM structure changes, review your integration tests and selenium-based tests. Additionally, make sure that your component CSS follows best practices. For supported integration tests, use the UI Test Automation Model (UTAM) and UTAM Page Objects, which stay up to date with changes in component structure. For supported Selenium-based tests, see Working with Shadow DOM Elements Using Webdriver. For supported CSS styling, see Style Components with Lightning Design System in the Lightning Web Components Developer Guide.

Class and Style Attributes Render with Extra Whitespaces

More components render with extra whitespaces in the class and style attributes. In Spring ’23, we announced an improved rendering time for your Lightning web components as a result of an optimization on how the framework handles static elements. That change influenced how the class and style attributes of your static nodes are rendered in the DOM. Extra whitespaces or unexpected characters sometimes appear in values for those attributes.

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 open source.

How: An element with class values can render with an extra space. For example, consider this element with the highlight and yellow class values.

<div class=" highlight yellow">

We recommend updating code that uses style or class attributes. Previously, you could query elements with an exact class name.

// Don’t do this
document.querySelector('[class="highlight yellow"]')

Revise the query to use a selector that ignores whitespace changes.

// Do this instead
document.querySelector('.highlight.yellow')

You’ve learned about important updates to Lightning Web Components, SLDS architecture, and how to prepare for native shadow DOM. Test your understanding of these topics by completing the quiz in this unit. In Unit 2, you learn about an additional component, the lightning-record-picker, and you’ll be tested with a hands-on challenge.

需要帮助？

了解更多