📢 Attention Salesforce Certified Trailblazers! Maintain your credentials and link your Trailhead and Webassessor accounts by December 6th. Learn more.
close
•
Start tracking your progress
Trailhead Home
Trailhead Home

Push and Deploy Lightning Web Component Files

Learning Objectives

After completing this unit, you’ll be able to:
  • Push samples to a scratch org.
  • Configure Lightning web component files for display in an org.
  • Deploy your files to an org.
  • Verify component behavior in an org environment.

Step up to an Org

It’s time to leave the Lightning Web Components Playground for a bit, although you’ll find it a very useful place to visit. In this unit, we develop a Lightning web component using a scratch org, VS Code with the Salesforce extension, and GitHub.

The development tools Salesforce provides simplify the process, and we have demo projects in GitHub that we use to speed things along. These demos let us see a Lightning web component project in its entirety.

What You Need

As stated in the first unit, you need some familiarity with Salesforce DX to continue. We use git from the command line (you can also use the desktop client, Command Palette in VS Code, or other familiar tool) and the Salesforce CLI. Specifically, to complete this unit, you need:

  • GitHub account
  • IDE, such as Visual Studio Code
  • Salesforce CLI
  • Dev Hub enabled org
  • My Domain deployed to users in your Dev Hub enabled org

    (Playground orgs created within Trailhead have My Domain deployed for you, but Developer Edition orgs you’ve associated with your Trailhead account, manually, need you to enable and deploy My Domain.)

Once you have a GitHub account, you can meet the rest of these requirements by completing the Quick Start: Lightning Web Components project and then enabling Dev Hub from the Setup menu in your org.

Clone and Push the E-Bikes Demo

Use the E-Bikes Lightning Web Components Sample Application, and the Salesforce CLI to push files to a scratch org.

  1. On your filesystem, create a local project folder, such as trail-comp.
  2. In the project directory, follow the instructions for Installing E-Bikes using Salesforce DX.
Note

Note

Install this using a scratch org for the DE org you associated with Trailhead in the Quick Start. The org should already have My Domain enabled and deployed to all users. In Setup, also ensure the org has Dev Hub enabled.

In your scratch org, when you click App Launcher. to open App Launcher, select the E-Bikes app. (If your scratch org opens in Salesforce Classic, switch to Lightning Experience.)

E-bikes app tile.

Click the Product Explorer tab to see Lightning web components that filter the list and display details in a tile (you might need to refresh the page).

E-bikes app component parts.
  1. productFilter: sets values for productTileList.
  2. productTileList: arranges the tiles based on the productFilter values.
  3. productTile: displays summary information for available items and is clickable.
  4. productCard: displays item details when a tile is clicked (similar to the bikeCard you just created).

The Component Configuration File

One other file we haven’t covered yet is the component configuration file. This file provides metadata for Salesforce, including the design configuration for components intended for use in Lightning App Builder.

The files that make up a component, including the configuration file.

We haven’t covered configuration files yet, because we’ve been playing in the playground. Now that you’re going to start using the content within an org, you must include a configuration file. This file has the extension .js-meta.xml.

You’ll notice the ebikes repo components all have this configuration file. Here’s an example from the ebikes repo:

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>45.0</apiVersion>
    <isExposed>false</isExposed>
    <targets>
        <target>lightning__AppPage</target>
        <target>lightning__RecordPage</target>
        <target>lightning__HomePage</target>
    </targets>
    <targetConfigs>
        <targetConfig targets="lightning__RecordPage">
            <objects>
                <object>Product__c</object>
            </objects>
        </targetConfig>
    </targetConfigs>
</LightningComponentBundle>
Required
apiVersion binds the component to a Salesforce API version.

isExposed (true or false) makes the component available from other namespaces. Only set this to true to make a component usable in a managed package or by Lightning App Builder in another org.

Optional
targets specify which types of Lightning pages the component can be added to in the Lightning App Builder.

targetConfigs let you specify behavior specific to each type of Lightning page, including things like which objects support the component.

See the documentation for the full list of supported syntax.

Displaying a Component in an Org

You have two options for displaying a Lightning web component in the UI.

  1. Set the component to support various flexipage types (home, record home, and so on) then add it to a flexipage using the Lightning App Builder. This is the simplest approach and the one you follow in this unit.
  2. You can also create a tab which points to an Aura component containing your Lightning web component. The Lightning Web Components Recipes repo uses this approach. You can see the required pieces in the repo.

Set Up Lightning Web Component Files for Use in an Org

You’re going to take the example from the previous unit and add it to the ebikes project. Name it the bikeCard component and push it to your scratch org.

Note

Note

We’re not defining any styling of our own, so we don’t need a CSS file.

The files you need to push a component to an org:

bikeCard.html

<template>
    <div>
        <div>Name: {name}</div>
        <div>Description: {description}</div>
        <lightning-badge label={material}></lightning-badge>
        <lightning-badge label={category}></lightning-badge>
        <div>Price: {price}</div>
        <div><img src={pictureUrl}/></div>
    </div>
</template>

bikeCard.js

import { LightningElement } from 'lwc';
export default class BikeCard extends LightningElement {
   name = 'Electra X4';
   description = 'A sweet bike built for comfort.';
   category = 'Mountain';
   material = 'Steel';
   price = '$2,700';
   pictureUrl = 'https://s3-us-west-1.amazonaws.com/sfdc-demo/ebikes/electrax4.jpg';
 }
Note

Note

Values like name work in this context without the @track decorator because you use the value once. Once it’s set, the component doesn’t need to re-render for a value change. Typically, your component loads dynamic values and you do need @track.

bikeCard.js-meta.xml

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <!-- The apiVersion may need to be increased for the current release -->
    <apiVersion>45.0</apiVersion>
    <isExposed>true</isExposed>
    <targets>
        <target>lightning__AppPage</target>
        <target>lightning__RecordPage</target>
        <target>lightning__HomePage</target>
    </targets>
</LightningComponentBundle>
  1. Save all of these under ebikes-lwc\force-app\main\default\lwc so you see something like the following (from VS Code): bikeCard component file structure.

    Lightning web components follow web standards. The HTML standard recommends that custom element names contain a hyphen. However, the Salesforce platform doesn’t allow hyphens in the component folder or file names. So we use camelCase naming conventions here.

  2. From the ebikes-lwc directory, push the new files to the same scratch org you created for the E-bikes demo app.
    sfdx force:source:push
  3. Open your scratch org.
    sfdx force:org:open

Create a New Page for Your Component

Since we set up our component configuration file to enable the use of the component in Lightning App Builder, use the UI to create an app and add your component to it.

  1. In Setup, enter Lightning App Builder in the Quick Find box and then select Lightning App Builder.
  2. Click New.
  3. Select App Page and Click Next.
  4. Give it the label Bike Card and Click Next.
  5. Select One Region and click Finish.
  6. In Lightning App Builder, scroll down the Lightning components list on the left side until you see your bikeCard component. The bikeCard component option in Lightning App Builder Custom component menu.

Now you can drag it onto the page. Save the page, Activate it, and bikeCard component shows up on the assigned page.

  1. Drag your bikeCard component to the top of the page layout until you see the bike appear.
  2. Click Save.
  3. Click Activate.
  4. Keep Activate for all users selected. And, optionally, change the name or icon for your app.
  5. Click Save.

    You’re asked to add your page to navigation menus, but you don’t need to You can still get to your page in this environment.

  6. Click Finish.
  7. Click Back in the upper right corner to exit the Lightning App Builder.
  8. Click App Launcher. to launch App Launcher, and search for your “Bike Card” page.
  9. Open it and see your component working in the UI. Your Bike Card app in Lightning Experience.

There you go, a shiny new bike. You’ve pushed a component to an org, seen it on the page, and can verify it in the UI.

Deploy Files

Great. Your component works in your scratch org. Scratch orgs are useful for experimentation and development. To complete the challenge for this unit, you’ll need to deploy the component files to your Dev Hub enabled org. For example, here’s how you can deploy the E-Bikes demo files to your org.

  1. Authenticate with your Dev Hub org (not the scratch org). You might need to log out of the scratch org, first.
    sfdx force:auth:web:login -d -a myhuborg
  2. Deploy the project files from the ebikes-lwc directory with the username to log in to the Dev Hub org (not the scratch org).
    sfdx force:source:deploy -p force-app -u <username>
  3. Set the permissions in your org.
    sfdx force:user:permset:assign -n ebikes -u <username>
Tip

Tip

Sometimes, when you’re working with scratch orgs and production orgs, you want to pull files from your scratch org to capture any changes you made in the scratch org. Then, you can deploy those files to your production org. In this case, we don’t need the changes from the scratch org; our source is entirely local. We’re simply deploying what we have locally to the Dev Hub org. You can learn more about the recommended deployment process in the Org Development Model module linked in the Resources section at the end of this unit.

In the next unit, you build an interactive component with event handling and deploy it to your org for testing.