Salesforce DX is now one among the top tech topics of the year. For those who are new to it, Salesforce DX is a developer platform which offers a brand-new experience to developers and administrators, and it is constantly evolving. Salesforce DX introduced many tools and capabilities which are familiar to the developers as they found in many other platforms, but made more streamlined on DX. It includes but not limited to:
- Source-driven developmental approach
- Version control
- Modular packaging model
- Headless deployment etc.
In this article, we will further discuss some basic elements which the developers need to be aware of.
Breaking up code base to modules
One of the primary concepts of Salesforce DX is the usage of the modular packages in contrast to the monolithic codebase applicable for the entire Org. Most of the developers now use this standard approach to identify the potential for their modules effectively:
- Custom apps – In an org, the custom apps are meant to group a related set of objects and codes. This can be a good starting point to come up with a comprehensive list of modules.
- AppExchange – When org has AppExchange installed, it will be more likely to have the custom code and also the related config. Each of the packages installed will have its own module of closely related customizations.
- Open source packages (unmanaged) – Building on DX, there are many open source libraries as well as frameworks coming into the picture like apex-commons or financial force lib to name a couple, which you can instantly install on org to cut short the developmental efforts.
Renaming the metadata to map packages
While breaking the codebase into packages, Flosum.com developers also should ensure that the metadata is not getting duplicated on various packages as it will result in some unexpected behaviors. Say for example, if there is a custom field getting included in two different packages and the definitions are not the same, then further deployment of the package will tend to overwrite that specific field’s definition on some other package.
To tackle this, developers need to follow a specific naming convention on metadata prior to moving them to the DX package. One should prefix all the custom metadata with the package name to which it is supposed to go. Once this is done properly, it can further smoothen the task of moving metadata to DX packages.
Usage of dependency injection
Another challenge developers face when transitioning is to decouple the dependent packages, and the solution for this is to form a dependency injection smartly using Salesforce configuration. If there is a base Selector class which is in the Core package which is meant to retrieve the records from subjects like an Account object. Such a Selector class will be aware of all Account fields in the Core package so that these fields can be included in the SOQL query as and when the Account records has to be retrieved.
It is a great move that Salesforce DX finally focus on the core developer side of the platform. We may expect more in this line in the coming year too, which will further make app development and deployment a breeze for the developers and administrators.