Beginner 25 min read

Exercise: Create, Deploy, and Test an LWC in a Real Org

By the end of this lesson, you'll be able to:

  • Execute the full local-development cycle: authenticate, generate, deploy, verify
  • Confirm a newly deployed component appears and renders correctly in an org
  • Practice the retrieve workflow after making an org-side change

Prerequisites: "Local Development Workflow and Source Control Basics"

The Full Cycle, End to End

# 1. Authenticate
sf org login web --alias practiceOrg

# 2. Generate the component
sf lightning generate component --name practiceCard --type lwc --output-dir force-app/main/default/lwc

# 3. Build a minimal template and JS (reuse Module 1's
#    Hello Salesforce shape, renamed to practiceCard)

# 4. Deploy
sf project deploy start --source-dir force-app/main/default/lwc/practiceCard --target-org practiceOrg

Then add practiceCard to a Lightning page via App Builder, and confirm it renders.

Verifying the Deployment Succeeded

Three separate checks, not just one:

  1. The CLI output shows a Deployed status for the component.
  2. Setup → Lightning Components lists the bundle.
  3. The actual Lightning page shows it rendering correctly.

A "Deployed" status in step 1 is necessary but not sufficient — it confirms the files were accepted, not that they look or behave correctly. Step 3 is the one that actually matters.

Practicing the Retrieve Workflow

Make a small configuration change directly in App Builder — if the component exposes a configurable property, change its value there. Then run:

sf project retrieve start --source-dir force-app/main/default/lwc/practiceCard --target-org practiceOrg

and inspect what, if anything, changed locally. You'll often notice that a component's placement on a page is stored separately (on the page's Flexipage metadata), distinct from the component bundle's own configuration — a distinction worth noticing firsthand rather than just reading about.

What You've Actually Practiced

This exercise isn't really about the practiceCard component itself — it's a rehearsal of the exact cycle used for every remaining lesson in this course: build locally, deploy, verify in an org. Building comfort with this loop now removes friction from every project ahead.

Exercise

Write out, in order, the exact sequence of CLI commands to authenticate to a new org, generate a component named practiceCard, and deploy it.

Show hint

Three commands, in order: login, generate, deploy.

BASH

Exercise

Challenge: after deploying practiceCard, you change one of its configurable properties directly in Lightning App Builder. Explain whether running sf project retrieve start would pull that specific change back into your local .js-meta.xml, and why or why not.

Show hint

Consider where a component's page placement/config is actually stored versus the component bundle itself.

BASH

Exercise: Create, Deploy, and Test an LWC in a Real Org Quiz

1. What is the correct order of commands to authenticate, generate, then deploy a new component?

2. A "Deployed" status in the CLI output guarantees the component renders correctly on a page.

3. What does a "Deployed" CLI status actually confirm?

4. Why is visually checking the org after a deploy an important habit?

5. Where is a component's configuration value for one specific page placement typically stored?

6. What is the real purpose of this exercise, beyond the specific practiceCard component?

Log in to submit the quiz and save your score.

My Notes

Log in to keep private notes on this lesson.

Questions about this lesson

No questions yet — be the first to ask.

Log in to ask a question about this lesson.

Summary

A compressed, hands-on rehearsal of the exact cycle — build locally, deploy, verify in an org — that repeats for the rest of this course, and for the rest of a real LWC developer's career.

Log in to track progress
← Local Development Workflow and Source Control Basics Anatomy of a Component →