The use of factories in Salesforce Lightning Web Components – good practices

The factory in Lightning Web Components as a set of information about an object

The first use is to collect all the needed information describing an object in one place.

Figure 1 – opportunityFactory.js

The simplest factory contains information on an object and its fields. In the factory, we import references to objects and fields. Next, we group and export them so that they could be available in other modules.

Figure 2 – Import of references

Benefits:

• Code is organized as the whole object description is in one place, not scattered, and not duplicated in other modules.
• Any changes in fields name are done in only one place, without refactoring the code.
• Field and object reference names are common for the entire project.

If we need different sets of fields in different modules, we can expand the factory with new modules or add parameters to a getFields method in a simple way.

Figure 3 – Adding a parameter to the getFields method.

The factory can also be extended with methods related to an object: downloading single records and lists, as well as creating and editing.

The factory in Lightning Web Components associated with an implemented functionality

The second type of factory means factories concerning implemented functionality and closely related to one Apex class. In this attitude, we begin to use other design patterns, including an adapter. Let us begin with a simple example:

Figure 4 – contractFactory.js

Here, we have two classic methods – downloading a record with a parameter of an ID type and saving a record with three different parameters:

• contract – record to be saved;
• products – a list of records to be saved;
• deletedProducts – a list of records to be deleted.

Creating a factory that is an adapter is the connection between a layer of LWC and layer of data that is, in this case, Apex class. Such division brings benefits. First, separation of the layers is, per se, a good practice. In particular modules, we do not have to import backend methods or know its structure and parameters. Transparency and avoiding code redundancy are obvious benefits.

Less obvious advantages can be spotted in real project situations. Let us analyze the usual task of a front-end developer: “Implement functionality of record edition.”

The data layer already exists, and we do not have the ability to change it.

The class containing the necessary methods is as follows:

Figure 5 – The class containing necessary methods

The savelt function has one entry parameter of a string type that is deserialized to a ContactWrapper class. The meaningless name and parameters are the classic example of a bad developer’s practices. Kind of everyone knows that, and yet, this is a code we see every day, especially in older projects. It would be best to change the data layer while we carry out our frontend tasks. Unfortunately, for various reasons, it is not always possible. In our task, we have to execute the savelt function and other functions of the EditContractController class in different code places. The execution of only the savelt method and data serialization is surely not the best solution. And in such case, the factory comes to our aid.

Figure 6 – saveContract method

When we already have such an implemented factory, importing and executing the saveContract method in modules is enough. This method has two obvious parameters, and its name meets the requirements of a self-documenting code.

There are many more situations similar to the ones described above. The solution always comes down to modularization and mutualization of the code. Building a factory that is an adapter facilitates not only writing the code. We gain even more during maintenance tasks and the ones that are related to the code refactoring. Let us get back to the example with the savelt method and reverse the situation. A backend developer gets a task to optimize the code of the EditContractController class. Thanks to the existing factory, frontend changes are limited to one place. The solution is time-saving and minimizes the possibility of errors.

Benefits of using factories in Lightning Web Components

Summarizing, the main benefits of factories are as follows:

• Modularization
• Code duplication avoidance
• Naming standardization
• Refactoring simplicity

This is only a part of the possibilities to use the pattern proposed by me during writing modules of Lightning Web Components. I have no choice but to encourage every developer to use it on a daily basis and discover its advantages.