This is a living document about a common sense approach to developing reusable Lightning components. It might change over time.

Salesforce documentation

• Lightning Developer Guide
• Lightning Component Library

As well as the instance specific component library

Principles

• Components shall serve a single purpose, designed for reusability
• Components shall use the most feasible least code approach
• Components shall not contain country specific logic in the front-end
• Components shall be documented and tested
• Components shall use composition over inheritance. Inheritance is NOT forbidden, use it wisely
• Components shall observe case sensitivity even for non case sensitive item (e.g. field names)
• Components shall prefer component markup over html markup (e.g. lightning:card over div class="slds-...")
• Components shall use component navigation (if navigation is needed)

Naming

Related files and components need to be named so they appear close to each other. E.g. a component "VehicleInfoList" that depends on inner components. Those would also start with "VehicleInfo" e.g. "VehicleInfoCard" "VehicleInfoLineItem", "VehicleInfoInterested" etc.
Files should be named like this:

• SalesProcess.cmp
• SalesProcessController.js
• SalesProcessHelper.js
• SalesProcess[WhatEvent].evt
• SalesProcess.SVG

Interfaces

• A component shall only implement the interfaces that it actually uses.
• A component that relies on a current record, shall not use "availableForAllPageTypes" and must implement "hasRecordId" and the attribute "recordId".
• Components that are not used on a page layout, but rather inside other components shall not implement interfaces ("availableFor...") that make them appear in the page editor
• Components shall only implement the interfaces they actually use. Avoid interfaces the component "might use in future"

Data access

Components shall use the "least code" principles for data access. To be checked in this sequence:

1. Does the component need data access or can the attributes of it provide all the input it requires?
2. Can lightning:recordForm be used?
3. Can lightning:recordEditForm and lightning:recordReadForm be used?
4. Can force:recordData be used?
5. Is a custom @AuraEnabled method in the controller needed for data provision?

This doesn't preclude fetching Meta data or configuration. Ensure to use storable actions where feasible. More principles:

• Use data change handlers where appropriate
• Use component events

Code principles

This section probably will expand over time

• Code needs to be readable
• The controllers (both client and server side) shall be light modules that marshall actual work to helper classes and helper functions
• In Apex helper classes shall be instantiated using factory classes - this allows intoducing country specific behavior
• All Apex helper classes shall be based on Interfaces
• Methods and functions shall be single purpose and not exceed a page size. Break them down (makes them more testable anyway) if to big
• Don't copy/paste
• Run PMD (free download) on all Apex (eventually on JavaScript too)
• Operations that can fail need to be handled with try/catch or its equivalent
• Use @ApexDoc and @JSDoc style comments

Testing

• All components need test code: both for Apex (natural) and the client side component.
• A component is incomplete without a "Lightning testing service" test.
• Use assertions generously!

Documentation

• Lightning components have a description
• Each lightning component comes with a documentation section - don't waste time documenting them outside Salesforce.
• Use the documentation to briefly explain what it does (no Pulitzer price for this writing!).
• Include at least one example in the documentation

Parameter

• Components that can be dragged onto a page can benefit from having parameters the page maintainer can use to configure the component, thus increasing reusability and limit the number of components that need to show up in the palette.
• Parameter documentation - Check the documentation for details.
• If a component is usable only for a specific object page, add that to the Design Resource.

As usual YMMV

The Salesforce API is a great way to access Salesforce data and can be used with tools like SoqlXplore or the Salesforce Workbench. The API uses OAuth and a Bearer Authentication, so some steps are required to make that work in Postman

Prepare Salesforce

You will need a connected APP. I usually create one that is pre-approved for my user profile(s), so I don't need to bother with the approval steps in Postman. However you could opt for self-approval and access the app once to approve its use, before you continue with the command line. Note down the ClientId and ClientSecret values.

Prepare Postman

Postman has great build in support for all sorts of authorization interactively. However my goal here is to fully automate it, so you can run a test suite without manual intervention. First stop is the creation of one environment. You can have multiple environments to cater to different Salesforce instances.

Important Never ever ever store the environment into version control. It would contain credentials -> bad bad idea!

My environment variables look like this:

{
 "CLIENT_ID" : "the ClientId from Salesforce",
 "CLIENT_SECRET" : "The ClientSecret from Salesforce",
    "USER_ID" : "some@email.com",
    "PASSWORD" : "DontTell",
    "LOGIN_URL" : "https://login.salesforce.com/"
}

Providing the Login URL allows to reuse postman collections between Sandboxes, Developer Orgs or Production Orgs without the need to actually edit the postman entries. Next on the menu: getting a token