In mid-2020 we started a project to build small Salesforce components that could be added to any application or even a registration page. That project has grown to include twelve components currently in production and many more on the way. We publish the components on the AppExchange for free so any Salesforce administrator can install them into their org to try them out. Our team builds components that are utilities that can help us on a daily basis, or complement our other work in some way.
Lightning Web Components
There are a few approaches we could take to build components like these, but we wanted to take advantage of the newer Lightning web component architecture. It uses JavaScript, HTML, CSS, and the Lightning Design System. When we need to access custom and standard object definitions or build and call REST APIs, we use the Salesforce Apex programming language.
Lightning web components are a powerful tool because they present data to the client in a dynamic and reactive way. Most components are designed to directly support the Salesforce users who will be interacting with them. This approach allows our team to build for desktop and mobile with very few differences in the code structure. And the Lightning Design System is crucial for designing and developing a UI that is consistent with the rest of the Salesforce experience and is easy for the end-user to understand.
Even though all the components are “components”, some of them could be classified as “sub-components”, meaning that one could be nested and work inside another. This allows the team to distribute tasks better and work more efficiently. It also allows the components to be scalable and to add more features to a single component. It also has the advantage of making the work neater: the code is more organized as each component has its own functionality.
Customer-centered Logic
When creating a component that runs in a complex environment like Salesforce, we want to be sure to minimize the number of interactions with the server. Customer-centered logic helps us reduce response time and to create elements that interact with the client faster. This approach lets the server delegate many of its responsibilities to the browser. Since it acts as a controller, all the user’s logic is handled by the browser.
Developing in this way requires a disposable cache that stores data locally, reducing the response time. The approach is called a “View-Controller-Controller-Model” because it has both a server-side and a client-side controller. Other frameworks such as Visualforce do not interact as quickly with the customer because they continuously consult the backend and request information and/or approvals. They depend 100% on the server. The server has to handle all the user’s requests and analyze what the user needs, then access the database, answer the question, and then render the page for the user. Not very efficient.
Component Ideas
The process of building a Lightning Web Component starts with a brainstorming session. Once all the ideas have been discussed, the team does a reality-check and chooses the most Lightning web component-friendly options. Then a team is designated to research available APIs on the market and determine which libraries they need. It’s only at that stage that we determine if it is feasible to develop that new component. If it is, a designer then creates a sketch with the layout, titles, logo, and color palette, and the development team starts building the components and Apex classes.
We currently have three Lightning web components published on the AppExchange, including Oktana Calendar and Oktana Youtube, with more components already in the security review process. It takes time for the Salesforce security team to complete their review and approve any app or component, and that review process has become even more rigorous recently. We’re excited to share with you our new components as they’re approved and published on the AppExchange. Keep an eye on this blog or check our Salesforce AppExchange listings page.
There are a few approaches we could take to build components like these, but we wanted to take advantage of the newer Lightning web component architecture. It uses JavaScript, HTML, CSS, and the Lightning Design System. When we need to access custom and standard object definitions or build and call REST APIs, we use the Salesforce Apex programming language.
Lightning web components are a powerful tool because they present data to the client in a dynamic and reactive way. Most components are designed to directly support the Salesforce users who will be interacting with them. This approach allows our team to build for desktop and mobile with very few differences in the code structure. And the Lightning Design System is crucial for designing and developing a UI that is consistent with the rest of the Salesforce experience and is easy for the end-user to understand.
Even though all the components are “components”, some of them could be classified as “sub-components”, meaning that one could be nested and work inside another. This allows the team to distribute tasks better and work more efficiently. It also allows the components to be scalable and to add more features to a single component. It also has the advantage of making the work neater: the code is more organized as each component has its own functionality.
Customer-centered Logic
When creating a component that runs in a complex environment like Salesforce, we want to be sure to minimize the number of interactions with the server. Customer-centered logic helps us reduce response time and to create elements that interact with the client faster. This approach lets the server delegate many of its responsibilities to the browser. Since it acts as a controller, all the user’s logic is handled by the browser.
Developing in this way requires a disposable cache that stores data locally, reducing the response time. The approach is called a “View-Controller-Controller-Model” because it has both a server-side and a client-side controller. Other frameworks such as Visualforce do not interact as quickly with the customer because they continuously consult the backend and request information and/or approvals. They depend 100% on the server. The server has to handle all the user’s requests and analyze what the user needs, then access the database, answer the question, and then render the page for the user. Not very efficient.
Component Ideas
The process of building a Lightning Web Component starts with a brainstorming session. Once all the ideas have been discussed, the team does a reality-check and chooses the most Lightning web component-friendly options. Then a team is designated to research available APIs on the market and determine which libraries they need. It’s only at that stage that we determine if it is feasible to develop that new component. If it is, a designer then creates a sketch with the layout, titles, logo, and color palette, and the development team starts building the components and Apex classes.
We currently have three Lightning web components published on the AppExchange, including Oktana Calendar and Oktana Youtube, with more components already in the security review process. It takes time for the Salesforce security team to complete their review and approve any app or component, and that review process has become even more rigorous recently. We’re excited to share with you our new components as they’re approved and published on the AppExchange. Keep an eye on this blog or check our Salesforce AppExchange listings page.
