In this course, you’ll learn how to implement custom, highly-reusable, and flexible Lightning Components that can be easily combined into compelling, responsive pages that run in Lightning Experience and Salesforce Mobile.
Play by Play is a series in which top technologists work through a problem in real time, unrehearsed, and unscripted. In this course, Play by Play: Developing Highly Reusable Salesforce Lightning Components for Lightning App Builder, Steve Drucker and Don Robins demonstrate how to design and build loosely coupled Lightning Components for maximum reusability in both mobile and desktop Lightning pages. Learn about how to maximize the use of component events, while limiting the use of application events to specific cases where they’re truly required, build out additional components, tie them into a flexible architecture, and implement responsive design with the Lightning layout component. By the end of this course, you’ll have gained some great perspective around how you can apply this architectural approach and sample code to build your own reusable, responsive, and flexible Lightning Components, pages, and design templates.
Steve Drucker is the former President of Fig Leaf Software, the Washington D.C. based technology solutions firm that he founded in 1992 and sold in 2018. He is a certified technical trainer (CTT+) and certified instructor for a dozen web development products.
Don Robins is a well known Salesforce MVP, instructor, author, and speaker.
A custom business application developer for more decades than he cares to
admit, he focuses on Salesforce technical instruction and knowledge
Course Overview Welcome to this Salesforce Play by Play with Pluralsight. Salesforce Play by Play is an interactive series, where we sit down with Salesforce experts such as MVPs, consultants, developers, and architects to discuss common challenges faced every day by Salesforce customers. We'll be learning while discussing concepts and debating trade-offs on various approaches to solving real-world problems. We learn by reviewing system configurations or writing code, and then exploring the benefits of any particular solution. In this course, we challenge Steve Drucker, Founder and Chief Innovation Officer at Fig Leaf Software in Washington D. C. , to show us how to design and build loosely coupled Lightning components for maximum reusability in both mobile and desktop Lightning pages. First, Steve walks us through some of the considerations around tightly coupled versus loosely coupled components, and clarifies the benefits of organizing component design to promote a robust and maintainable component architecture. Next, he demonstrates how to maximize the use of component events while limiting the use of application events to specific cases where they're truly required. You'll watch as he rapidly builds out additional components and ties them into his flexible architecture, and he'll show how to maintain tight component encapsulation while synchronizing data changes with the Lightning Data Service to maximize performance. Along the way, we'll review how to implement responsive design with the Lightning layout component, as well as architectural patterns and anti-patterns such as adopting low-code best practices by leveraging out-of-the-box Lightning functionality as much as possible. By the time we're done, you will have gained some great perspective around how you can apply his architectural approach and sample code to build your own reusable, responsive, and flexible Lightning components, pages, and design templates. So please join us for Developing Highly Reusable Salesforce Lightning Components for Lightning App Builder. We hope you enjoy it.
Developing Components and Templates for App Builder Okay, let's get started in building our application. So we're going to go into our Developer Console, and actually even before we go into Developer Console, let's take a quick look at the applications that we're going to be building and the three major components that are part of it. So here I've got an example here called FWB Tight, this is an example of using the tightly coupled components, and you can see on the left-hand side I've got a tree control, so this is one of the new controls that are part of the winter release, and that's being dynamically populated with data from Apex. And now I can go and select a beer, and really the only beer that I personally feel is drinkable is Guinness. That you personally feel drinkable that's on this list, or in general? I think in general, actually. I'm a little bit of a Guinness snob, you know, and beer is food. You don't have to sell me. You're preaching to the choir. So I click on Guinness, so that goes over to our Contact results, we're pulling that data, again, from Salesforce. I added in a custom field to track the beer ID associated with every contact, and then when I click on that, that's going to go and, again, pull the data for the contact, it's doing that through Lightning Data Service and displaying it in a little card. And so one of the goals here is this is a responsive app, so as I scroll we can see it's going to go and the table is going to go and shift, and we've got a little bit of extra work we've got to do there on our responsiveness, but you kind of get the general idea behind that.
Using Lightning Data Service to Synchronize Data Views So now we've got the model where we've got the tightly coupled, and we've got the model where we've got the loosely coupled. I imagine when things are loosely coupled there's some issues around data synchronization. Yep, yeah, and for loosely coupled, really the major problem that we have is that we want to make sure that we've got really good encapsulation in the components, so that means that every component needs to be responsible for making its own data fetches. Even if you have two components that are fetching the same data at more or less the same time, keeping those in sync used to be a real challenge, but as of this release in winter, we now have Lightning Data Service, and so Lightning Data Service allows us to perform single record data fetches and data updates. Basically, it does CRUD, create, read, update, delete, right, on a record, and will actually keep that data in sync across all of the components that you have. So it's really, really good for creating loosely coupled apps where everything needs to be looking at more or less the same data, or could potentially be pulling repetitive data. So in other words, if you change something in one component, the other component is going to know about that data change and react accordingly? That is what's supposed to happen in theory. We will actually see that. I plan on moving to theory Indiana any time now, but yes, in theory there is supposed to be data synchronization, and also if two components try to fetch the same record, only one will get it and that data will be transferred to both components. So, it's really great from a performance standpoint, which again, is really helpful from my standpoint as an architect of performance, stability, robustness, and security. I imagine it uses caching as much as it can. It's using caching. It's actually writing out a lot of the data to the browser's local database instance, and you can see this if you actually go into the debugger.