Stabilizing Salesforce Lightning Development With the React Design System

The transition from Salesforce Classic to Lightning has been a rocky road for some Developers. This journey was dramatically stabilized once we adopted the React design system for all front end (FE) Salesforce Lightning user interface (UI) development.

For one, the adoption of React no longer meant we were recruiting and hiring specialized “Salesforce Lightning Developers”, and instead focusing on generalist “React Front End Developers”, which vastly expanded the pool of available Developers.

React adoption has been steadily increasing in the web development ecosystem. In 2019 React reached a critical mass of 57% adoption by all new projects [1] and continues to grow.

Second, the workflow for React Developers starts in a localhost environment with rapid feedback provided by “hot reloading” components. This is in contrast to a cloud-driven workflow that deploys all changes to the cloud for compilation, testing, and UI layout feedback. "Hot reloading" improves team morale and allows Developers to make lots of small changes quickly.

Third, the one-way data binding nature of React with immutable records made it far simpler to rationalize page rendering flows. No global variables or two-way data binding results in minimal side-effects and more focus on the responsibilities of an individual component. One input and one output.

Fourth, use of Redux for storing state allows for rich user experiences that can leverage “time machine” undo / redo and what-if adjustment scenarios, which are critical features for our Financial Services focused spreadsheet and data grid experiences.

Fifth, the React community is actively involved in unit test automation. Our Front End team selected Jest and works with a variety of other test runners on a daily basis to assert all expected output and minimize regression bugs.

Salesforce requires 75% unit test coverage for backend Apex code, but front end unit tests are currently optional. As an ISV Developer, we strive for unit test coverage parity on both the front and back end.

At the time of this writing, the React design system supported 40 UI blueprints from the Lightning Design System.

Results

Recruiting decreased from about 90 days to 30 days since the job description was more focused on a readily available market.

Onboarding new Developers decreased from 6 weeks to 2 weeks. Most React Developers immediately recognized the patterns and best practices in place and were immediately productive. Developers were not required to learn Salesforce-specific Lightning or aura framework syntax or practices.

Sprints became far less volatile. Velocity was more consistent. Deliverables were inline with estimates.

Some enhancements incorporated by our Front End Team:

• Local installation of json-server running that serves mock API responses.
• Data Access Object (DAO) tier that serializes all client-server I/O to JSON. This removes all namespace prefixes and custom suffixes from API payloads.
• Auto lint and pretty formatting upon commit.
• Selenium macros
• A custom create-react-app utility for provisioning new React Lightning pages and components

Conclusion

The React design system for Salesforce Lightning is currently open source under a BSD 3 license and actively maintained (link). Any team can use or fork this library for free.

Rather than hiring a specialized full stack "Salesforce Lightning Developer", consider separating the roles into "React Front End (FE) Developer" and "Salesforce Backend (BE) Developer", with the latter being more Salesforce focused and certified. Allow the Front End role to independently contribute as a generalist.