Get Ready to Create an App

Before you can build your first app, create a project and connect it to your source control repository.

You won’t need your Trailhead Playground org to build this app. Instead, you’ll be using scratch orgs. We introduced these powerful and temporary environments in the previous unit. You’ll get a chance in the last unit to deploy a package to your Trailhead Playground.

A Salesforce DX project is a local copy of your package metadata, a group of related code and customizations. It also contains the core assets required to synchronize local project source and metadata with your scratch orgs. Create the project on the same machine where you installed Salesforce CLI, then sync this project with your VCS repository.

In this module, we create a simple geolocation application with Aura components.

As of the Spring ‘19 release (API version 45.0), you can build Lightning components using two programming models: the Lightning Web Components model and the original Aura Components model. Lightning web components and Aura components can coexist and interoperate on a page. This content covers Aura components. For more information about Lightning web components, see Introducing Lightning Web Components.

So let’s get started. Create a project called geolocation.

1. In a terminal or command window, navigate to where you want your project located.
2. Create the project:

   sf project generate --name geolocation

   This command creates a folder called geolocation, and scaffolds a new project with all assets in the proper folder structure. Here’s an example of a local project. You can see how a project evolves once you begin to add source code, Lightning components, and classes, just to name a few.
   
   
   

    

   
   
   

   Asset	Purpose
   sfdx-project.json	This file indicates that the directory is a Salesforce DX project. It contains project information and facilitates the authentication of orgs. It also tells the Salesforce CLI where to put files when syncing between the project and org. Within this file you specify: The paths to your source code, classes, and metadata, as located in one or more package directories, in this case, force-app. The namespace, if needed. The API version of your source. Salesforce CLI commands use this information to know what source to track between the project and the associated org.
   config/project-scratch-def.json	Determines the configuration of a scratch org, including which features and settings define its org shape. You can create a configuration file that your whole dev team can share.
   force-app	The folder that contains the source for your project.

Configure a Scratch Org Definition File

Scratch org definition files allow you to easily create scratch orgs with different features or preferences for testing. For example, you can turn Salesforce mobile web caching on or off by setting the enables1EncryptedStoragePref2 org preference. During development, disabling caching saves you from repeatedly refreshing the page waiting for your component code changes to take effect.

Optionally update the contents of config/project-scratch-def.json to make it more personal, such as changing the orgName property.

{
  "orgName": "Account Geolocation App",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "mobileSettings": {
      "enableS1EncryptedStoragePref2": false
    }
  }
}

Disabling secure and persistent browser caching has a significant negative performance impact. Always enable the setting in production.

Now that you understand the power of scratch orgs, here’s the basic workflow of when you use them in the Package Development Model.

1. Push your local source and metadata to a scratch org.
2. Pull any changes you make in the scratch org back to your local project.
3. Sync this project with your source control repo.

Your Dev Hub org edition determines how many scratch orgs you can create daily, and how many can be active at a given point. Trailhead Playgrounds are Developer Edition orgs. You can delete an existing scratch org to free up an allocation with the org delete scratch command.

But before we can play around with the workflow, we must first create a scratch org. Let’s do that now.

1. In the command window, change to the geolocationproject directory.

   cd geolocation

2. Create a scratch org with the alias GeoAppScratch.

   sf org create scratch --set-default --definition-file config/project-scratch-def.json --alias GeoAppScratch

Sometimes this process takes a few moments. We used these flags when launching the command:

• The --set-default flag indicates that you want this scratch org to be the default org for this project when running Salesforce CLI commands. To use a different org on a per command basis, you can specify the --target-org flag and specify another alias.
• The --definition-file flag is the path to the project scratch org configuration file.
• Remember our friend, the --alias flag, from the previous unit? It lets you refer to the org using its alias, GeoAppScratch, in future commands that accept the --target-org flag.

Scratch orgs come with some standard data based on the edition you choose. However, it’s important to add some sample data that’s more relevant to the app or package you’re building. So let’s use Salesforce CLI to create some sample accounts to test with our geolocation app.

1. Create the Marriott Marquis account.

   sf data create record --sobject Account --values "Name='Marriott Marquis' BillingStreet='780 Mission St' BillingCity='San Francisco' BillingState='CA' BillingPostalCode='94103' Phone='(415) 896-1600' Website='www.marriott.com'"

2. Create the Hilton Union Square account.

   sf data create record --sobject Account --values "Name='Hilton Union Square' BillingStreet='333 O Farrell St' BillingCity='San Francisco' BillingState='CA' BillingPostalCode='94102' Phone='(415) 771-1400' Website='www.hilton.com'"

3. Create the Hyatt account.

   sf data create record --sobject Account --values "Name='Hyatt' BillingStreet='5 Embarcadero Center' BillingCity='San Francisco' BillingState='CA' BillingPostalCode='94111' Phone='(415) 788-1234' Website='www.hyatt.com'"

   To continue to rock your developer world, we provide commands to easily grab data from your scratch org and pull it into your project. You can then commit that data to your source control repository, so you can reload it if you, or another developer, spins up a new scratch org.
   
   Whatever source control system you use, we recommend that you configure it to exclude the .sf folder from being added to the repository. This folder holds temporary information for your scratch orgs, so you don’t have to save it for posterity . In Git, you would add it to the .gitignore file.
   
   
4. In your Salesforce DX geolocation project, create a directory called data.

   mkdir data

5. Export some sample data.

   sf data export tree --query "SELECT Name, BillingStreet, BillingCity, BillingState, BillingPostalCode, Phone, Website FROM Account WHERE BillingStreet != NULL AND BillingCity != NULL and BillingState != NULL" --output-dir ./data

   You now have sample data that you can import in the future with this command. But don't do it now, we'll import the data into a different scratch org later.

   sf data import tree --files data/Account.json

   So far we’ve synchronized regular data. Now we’re going to turn to the really fun part—the code.

• Salesforce Documentation: Salesforce CLI Setup Guide
• Salesforce Documentation: Salesforce CLI Command Reference
• Salesforce Documentation: Salesforce DX Developer Guide
• Visual Studio Marketplace: Salesforce Extensions for VS Code