5 Practical Tips for Lightning Web Components Development

2023-08-25 — Frontend

5 Practical Tips and Tricks for Lightning Web Components Development. Compilation of the most valuable tips and tricks from my experience as a Salesforce Developer to boost your Salesforce frontend seniority.

1. Select proper tool

It’s very important to pick a proper tool for code writing. There are not so many options when it comes to LWC, my personal suggestion is to use VS Code with the Salesforce Extension Pack. I want to share the VS Code extensions that I use as a Salesforce Developer:

Salesforce Extension Pack
Project Manager - brings a “project” functionality to the VS Code
Git Lense - must have for everyone
Copy filename
One Monokai Theme - the quality of your code will increase when you will switch to the dark theme…
Code Runner - i’m using it to run small js code pices for testing

2. Understand what is LWC

Lightning Web Components (LWC) - is UI fraemwork made by Salesforce. It uses uses core Web Components standards and provides only what’s necessary to perform well in browsers supported by Salesforce. Because it’s built on code that runs natively in browsers, Lightning Web Components is lightweight and delivers exceptional performance. Most of the code you write is standard JavaScript and HTML. For my understanding the key feature of LWC are:

Modularity and reusability - You can create self-contained components that encapsulate specific functionalities.
High perfomance in comparation to Aura and VF
Open-Source - Salesforce made it open-source, so we can expect long-term support and maintance from community.

3. Use export/import

As was said before it’s modular by design so don’t be afraid using the export/import functionality. Modularity in LWC refers to the practice of breaking down your codebase into smaller, reusable components that can be easily managed and imported into other parts of your application. Here are some examples of modularity using export and import in LWC, I will use service components as an example:
modularityDemo.js

import { LightningElement } from 'lwc';
import { say } from 'c/service';
export default class ModularityDemo extends LightningElement {

    connectedCallback() {
        say('hello from bluecloud blog');
    }
}

service.js
Here you can see that js support different type of export. You are able to export function or object with the functions inside.

js allows us to export function even before initialization as you can see on the example below

this is valid

export { say }

const say = (text) => console.log(text);

this is also valid

export const say = (text) => console.log(text);

this is also valid

modularityDemo.js
Also you can import using asterisk * mark, it will import everything that was exported

import { LightningElement } from 'lwc';
import * as service from 'c/service';
export default class ModularityDemo extends LightningElement {

    connectedCallback() {
        service.say('hello from bluecloud blog');
    }
}

If you want to export a class in LWC, it’s also possible, I have create a Weapon.js file inside the modularityDemo lightning component bundle. Here is how to use a class export in lwc:
Weapon.js

export class Weapon {
    constructor(ammo, damage) {
        this.ammo = ammo;
        this.damage = damage;
    }

    fire() {
        console.log(`pew with ${this.damage}`);
        this.ammo -= 1;
    }
}

And we can use it in our modularityDemo.js in the any way we need

import { LightningElement } from 'lwc';
import { Weapon } from './Weapon'; //import of the class
export default class ModularityDemo extends LightningElement {
    connectedCallback() {
        const glock = new Weapon(15, 1);
        glock.fire();
        //console output will be:
        //pew with 1
        //and the ammo quantity will be decreased by 1
    }
}

You can use default keyword. The export default syntax allows you to export a single value from a module as the default export. When another module imports the module that uses export default, the imported value will be whatever value was exported as the default. You can only have one default export per module.

The choice is on your side but here are some general guidelines:

If you only need to export a single value from a module, or if the module represents a main feature of your application, use export default.
If you need to export multiple values from a module, or if you want to organize your code into smaller, reusable components, use export with named exports.

One more thing that I noticed many times on different projects, people doesn’t expose custom label imports in a separate file and that makes a code ‘dirty’. This is the example of this approach.

import { LightningElement } from 'lwc';
import Label_One from '@salesforce/label/c.Label_One';
import Label_Two from '@salesforce/label/c.Label_Two';
import Label_Three from '@salesforce/label/c.Label_Three';
import Label_Four from '@salesforce/label/c.Label_Four';
import Label_Five from '@salesforce/label/c.Label_Five';
import Label_Six from '@salesforce/label/c.Label_Six';
import Label_Seven from '@salesforce/label/c.Label_Seven';
import Label_Eight from '@salesforce/label/c.Label_Eight';
import Label_Nine from '@salesforce/label/c.Label_Nine';
import Label_Ten from '@salesforce/label/c.Label_Ten';
export default class ModularityDemo extends LightningElement {
    doSomethingWithLabels() {
        //
    }
}

My suggestion is to use helper file that will handle all the logic of the lwc label imports. Here is an example:
modularityDemoImportHelper.js

import Label_One from '@salesforce/label/c.Label_One';
import Label_Two from '@salesforce/label/c.Label_Two';
import Label_Three from '@salesforce/label/c.Label_Three';
import Label_Four from '@salesforce/label/c.Label_Four';
import Label_Five from '@salesforce/label/c.Label_Five';
import Label_Six from '@salesforce/label/c.Label_Six';
import Label_Seven from '@salesforce/label/c.Label_Seven';
import Label_Eight from '@salesforce/label/c.Label_Eight';
import Label_Nine from '@salesforce/label/c.Label_Nine';
import Label_Ten from '@salesforce/label/c.Label_Ten';

export default {
    Label_One, Label_Two, Label_Three, 
    Label_Four, Label_Five, Label_Six, 
    Label_Seven, Label_Eight, Label_Nine,
    Label_Ten,
}

And now we can use it in our main component
modularityDemo.js

import { LightningElement } from 'lwc';
import labels from './modularityDemoImportHelper'
export default class ModularityDemo extends LightningElement {
    labels = labels;
    //now all your labels are accessible with
    //this.labels
    doSomethingWithLabels() {
        
    }
}

Now code looks much clearer, but in programming there not so many undeniable truths so you can always chose your way of implementation. File structure:

├── modularityDemo
│   ├── Weapon.js
│   ├── modularityDemo.css
│   ├── modularityDemo.html
│   ├── modularityDemo.js
│   ├── modularityDemo.js-meta.xml
│   └── modularityDemoImportHelper.js

4. Don’t forget about decomposition

In general decomposition is a fundamental problem-solving technique that involves breaking down complex problems or tasks into smaller, more manageable parts. This is why you should use decomposition:

Reusability: By breaking your UI into smaller components, you can reuse them across different parts of your application or even in different applications. This not only saves development time but also ensures a consistent user experience.
Maintainability: Smaller components are easier to manage and maintain. When you need to make changes or updates, you can focus on a specific component without affecting the entire UI, reducing the risk of unintended side effects.
Clearer Code: Decomposition leads to cleaner and more organized code. Each component focuses on a specific aspect of the UI or functionality, making it easier to understand and reason about your codebase.

5. Dont ignore the documentation

Lightning Web Components is still under development. Check for updates and new features every release. Lightning Now group in Trailblazer community will help you to be updated on everything LWC related. Unfortunatelly Salesforce decided to remove their Playground but gave an ability to develop it locally. I will cover Lightning Web Component local development it in further blogposts. But anyway they still have great tools as component library and LWS playground to test new Lightning Web Security functionality. And don’t forget to visit an official documentation.