Quick Tip.

Salesforce DX already comes with Intellisense for Apex classes and the different primitive types. Eg. Strings

For SObjects it’s a per-project setting you need to enable once you have your project created. Open the Command Palette and choose SFDX: Refresh SObject Definitions

What the command does under the hood is it will create a class definition of the SObject and store them under the .sfdx folder/tools folder. These don’t get committed to version control as the .sfdx folder is by default ignored.

Each class has properties that allows the Intellisense to work.

Once enabled you are good to go.

If you want more tips and information on Salesforce DX checkout my youtube playlist where I cover them in detail.

There are two development models you can follow with Salesforce DX.

First is the package model where you develop against a scratch org and prepare all the components that are needed to deploy, similar to change sets but smarter as it handles the dependencies for you. We will talk about this more in the future.

The other method is what you would be most familiar with if you have been developing with Salesforce for sometime now(Force.com IDE/Mavensmate/IntelliJ), you develop changes against a sandbox and move the metadata to deploy to the target org till you deploy to production.

With Salesforce DX you can still continue to develop against a sandbox. You do not need to enable Dev Hub for developing against a sandbox or DE org.

Requirements ofcourse if you should have VSCode installed, the VSCode Salesfor ce Extension Pack and the Salesforce CLI.

Boot up VSCode and Open the Command Prompt and type SFDX : Create Project with Manifest

The scaffolding created will contain a manifest folder with a package.xml

The default package.xml adds the base ApexClass, ApexComponent, ApexPage, ApexTestSuite, ApexTrigger,AuraDefinitionBundle and StaticResource.

Next is to Authorise the Sandbox you want to work on, Go to the command pallete. SFDX: Authorize and Org.

Next right click on the package.xml and choose Retrieve Source in Manifest in Org.

Once done you can start modifying your code. Right click on a file to deploy it to the Source Org or enable the auto deploy on Save settings.

That’s it, you should now be able to work with your existing sandbox.

Check out my video and subscribe if you want more tips and suggestions.

If you run the cli command sfdx force:org:list and see a bunch of old orgs you recently authorized or scratch orgs that you no longer use.

You can easily clean them up by logging off from the org.

sfdx force:auth:logout -u <alias>

You get this confirmation screen and important reminder if you want to reuse your scratch org you must know the pasword before logging out.

If you don’t need the scratch org you can delete them with the command below.

sfdx force:org:delete -u <alias>

The title says it all if you have been developing before on Force.com IDE/ Mavenmate/IntelliJ and started using Salesforce DX. One that gets pretty tedious fast is manually pushing your code to your scratch org or deploying to your non-tracked org(DE/Sandbox).

To enable auto push/deploy simply edit the .vscode/settings.json. This folder can be hidden on Windows or Mac. On a Mac open the Finder and hit CMD+Shift dot(.) to display hidden files.

Add the following settings and set it to true.

"salesforcedx-vscode-core.push-or-deploy-on-save.enabled": true

My settings.json looks like below.

Another method to do this same steps is to go to the Code menu and choose Preferences then Settings.

Next click on Workspace tab then search for Salesforce

Under Salesforce Feature Previews(3rd one), tick the box under Salesforcedx-vscode-core › Push-or-deploy-on-save: Enabled

This is particularly useful specially for cloned repository where the .vscode folder is not part of the repository.

Don’t forget to update the .gitignore file if you are using version control and add the .vscode folder.

Happy coding!