Today we are talking about what’s new in Spring ‘20 Base Components. Greg Rewis, Director of Product Management for Lightning Components is no stranger to HTML, CSS, and JavaScript.  He joins me today to share some of the latest additions to the Base Component Library, including the ability to develop locally with Salesforce DX. He also shares his take on what it means to make Base Components open source. Spring ‘20 is shaping up to see a huge shift and new frontier for development. 

Show Highlights:

  • Why the Component Library is your one-stop-shop for development
  • The Component Playground as a resource and tool for finding and reproducing bugs
  • The introduction of the local development extension 
  • Open-sourcing of base components: what it takes to go through an official Lightning Base Component and making it open source

Resources:

Episode Transcript

Greg: And then I went to Macromedia to help build Dreamweaver to help kill the product that I had just sold to Adobe. And you know, everyone knows the joke was on me because Adobe bought Macromedia too, right. So anyways, I’ve been around. I’ve been doing this HTML, CSS and JavaScript stuff since literally the day it began.

Josh: That’s Greg Rewis, a Director of Product Management for Lightning Components here at Salesforce. I’m Josh Birk, a Developer Evangelist for Salesforce and here on the Salesforce Developer Podcast, you’ll hear stories and insights from developers, for developers. Clearly, Greg is no stranger to HTML, CSS, and JavaScript. And today, we sit down to talk about what’s new in Spring ‘20. Now remember, we only just launched LWC a year ago, and it was announced and released at the same time, and a big part of that lunch was the interactive base component library

 

Greg: well, so we’ve got several new things that we’ve been adding, and you first of all, I would just go back to, you know, make sure that everyone understands that, hey, if you don’t have the component library bookmarked, then you are literally missing out. Yeah, you’re doing it wrong, because that is literally where you know, that is your one stop shop, not only for looking at all of the components that my team is delivering for you, but even being able to, you know, do things like play around with those components that whether it’s right there on the components page, you know, in the mini playground, or using the actual playground and, you know, I want to give a huge shout out to the component library team that, you know, just absolutely crushed it when they built the playground. Because we now internally on my team, we actually use the playground almost every day is we’re doing your research on a bug for example. You know, one of the things that we asked, you know, some of our support folks to do when they file a bug, you know, we want to say hey, okay, can you show me this, can you repro the issue because otherwise I don’t want my engineers, you know wasting time trying to go reproduce a bug if you’ve already found it, tell me how you found it.

Josh: Right, right. And there’s something else new for spring 20, which falls along those same lines. Think about the current cloud based process for a UI developer working on a lightning component based interface. Even within Salesforce DX in the realm of scratch works every time you want to see a change, you have to push it to the cloud. And depending on what you’re working on, you may be trying to prove out or fix several small things before getting to see the bigger picture. And while that push might only take a few seconds, those seconds we’re going to be adding up time over time. So what if you didn’t have to do that process? Well, introducing local development.

Greg: local development, what is it? Well, it’s actually an extension. So it is an extension that you can you can find the command it is one line of code as an sfdx command, and that’s going to install basically a node server right here on your laptop. This connected up and ready to go. So now, let’s go back through that same process. Now let’s say I want to create a component. So in VS code, I can just say new lightning web component, boom, I’m ready to rock and roll. I dropped into the template or the HTML, maybe I pop in a lightning card and some text, right? I want to see it. I want to see it right now. I don’t want to go through the process of putting it on a page and all that I just need to see is this even what I’m looking for, you know, I choose Custom 85 is my icon. Is that the right one? I mean, I don’t know. Right. So I want to see it. Well, now, if you’ve installed the local development server, now what you get to do is you get to do right there inside of VS code, you just go to the folder that holds your component, so you know my hello world folder or whatever it might be. You right click and right there at the bottom of the right click menu is a preview of your component command from sfdx. And boom, will take you right over into the browser and We will launch the local development server with that component loaded up for you to look at. It’s not in an org anywhere. It’s not on a page anywhere. It’s just there.

 

Josh: So that’s clearly awesome. And a huge shift for us and a new frontier for development, Salesforce. And the first question that I had in my mind is, well, if it’s not in an org, and it only exists running up this note server, then how is it handling data?

Greg: I need data. Okay. Well, there’s sort of some good news, bad news there, right? So the bad news is we’re not in a position to like let’s say I had something that was needing a record ID let’s say for example, you know, I’m looking at a contact and I need to know what you know, account this contact belongs to, right. So I’m going to need to do some kind of a lookup, so you know, get that ID. We’re not quite there yet. But all I need to do is drop into my org, which is what I do is I just dropped into my org real quick. I go pull up guy. Let’s see Josh Birk. Okay, here you go. Boom. I’ll just grab your ID Then I’ll just pass that statically that down. Like let’s say I’ve got a record form, then for record ID, instead of doing a variable, you know, to find out what my record ID is, you know, using the UI API. Instead, I’ll just hard code that in there. I’ll just say, For right now, while I’m developing it, here’s my record form, record ID equals and I’ll hard code your record ID right in there. And boom, then it’s working literally as if I was sitting in or on that page.

Josh: So if I’m offline, what is the data source?

Greg: Now you’re not going to be as impressed. Yeah, you’re not.

Josh: But I’m pretty sufficiently wowed right now, so…

Greg: but here’s what we’re, here’s what we’re looking at. We are looking at coming up with a way for you to define some data. Right? Okay. So like, that’s what we’ve done in like the component library for things like data tables, right? Well, you’re not going to go out and query some data just to show that so So of course, we pass that as a as a static JSON file or you know, data structure. And those are the kind of things that we’re looking at as we move forward. So hey, I can I can give you a data structure right there, boom, and you’re going to see it as if you know you were actually online. So as long as you know what that data is supposed to look like, you can mock it and pass that back down to the component.

Josh: Today’s main focus is lighting components, lightning base components, updates to those some of the neat things are coming out Spring 20. But Greg did want to give a shout out to another feature that is coming out in while we’re talking about efficiency and tooling and things like that.

Greg: It’s a little nifty thing you could do with SOQL make a new file save it anywhere in your scratch or actually I just make you can save it anywhere because I put it into my force ignore but just call it josh.soql. So qL as your file ending when you do that. Now in VS code as you begin to type select will code for you code hunting, SoCal right there, and it gets even better because this You go, Okay, good. That’s great. I got code and whatever. But did I still write it correctly? Right? Is this going to return what I expect it to return? And I know we’ve all gone into the developer console before and execute anonymous and all of that. Well, now you don’t even have to do that. Now, in that SQOL document, just highlight the SOQL, you know, select contact, you know, whatever select name from account, let’s say, right, all you do is highlight select name from account. And then there’s a new SF dx command to run the SoCal command. And the output will be right there in the output window inside of VS code, so you can check your statements before you ever commit to them. Get it?

Josh: (Laughter) Okay, so, so seriously, in the full version of this interview, I do actually laugh it I think at pretty much all of Greg’s jokes. So moving on to our next topic, I want to talk about something that we actually as a company talked about back at Dreamforce. And that is the open sourcing of base components. And there’s a lot of reasons we’ve done that, but one of the things reasons is to give you some insight into how we build these components so that you can learn from them.

Greg: One of the things that has been, I tell you, I don’t know how many times over the last my watch almost two and a half years now that I’ve been the product manager for lightning buzz, I must have been asked at least 1000 times, show me the code. Let me see the code, I want to see the code. And you know, and here’s a funny thing. You know, what I generally ask back is when if you come up to me and say that then one of the questions that I’ve had in the past was why, what do you expect to get out of this? Why are you wanting to see the code? And let’s be honest, how do you learn? How do I learn any of the coding that I’ve done over my entire career, whether that’s HTML, CSS, or JavaScript, much of it has been learned by looking at other people’s code, right? I mean, what’s that old thing? You know, how does a developer code – Copy and Paste.

Josh: I believe I have been quoted as saying that sometimes a Stack Exchange is my IDE

Greg: that that is exactly right. So, so this is the thing, and this is a lot of folks, you know, when I would ask the question back, why why do you want to see it? What are you looking to get out of it? You know, let’s talk about that. Best practices, you know, how did you guys do it? Right? That’s a question and discussion that I’ve had quite often is, hey, we’re ramping up on LWC. We’re looking to learn best practices.

Josh: So there’s learning and there’s also the ability to go into the open source components and tinker with them, tweak them, create variants of them so that you can have functionality related to them that doesn’t need to be stamped officially by Greg’s team. So what does it take to go through an official lightning base component, which is a product of ours and making it open source?

Greg: So a funny thing happened on the way to that feature.So initially, you know, you think, Oh, well just open source it right. And right what, what does that mean? I’ll just put it in GitHub and open the door.

Josh: Just hit publish, right?

Greg Yeah, there you go. I’m done. Right? Well, yeah. No, not not in our world. Because you see the one little gotcha to this whole thing is that our base components, whenever you write, you know, your component, you go to use a base component, what’s the first word you write? Lightning? Whether it’s lightning colon or lightning dash, depending on whether you’re doing aura or LWC, but the first word you write is lightning. Mm hmm. Well, that’s the namespace that belongs to us. That belongs to me that in my team, we are the gatekeepers of the lightning namespace. And any of those folks out there in the world listening to the podcast here, you are an external developer unless you work for Salesforce but you are an external and external developers simply do not have access to the lightning namespace. And that’s for good reason.

Josh: I mean, that’s the nuts and bolts, you are tied directly into the mothership at that point

Greg: right, right. And so, so as much as we wanted to give you all of our source code, we realize that, hey, we’re not going to be able to do that. Because you I mean, while I could give you the source code, but it but you’re not going to be able to quote unquote, compile it or use it, because it’s in the lightning namespace. And you’re not allowed to put a lightning namespaced component into the system simply not happening. Because if you made a change to your lightning button, and I make a change to my lightning button, the one that’s actually being served who wins, right? And there there be complex and all sorts of craziness. So that’s why we don’t allow that. So we had to come up with a different solution. So we went back to the drawing board said, All right, how do we do this? And so what we came across Are did for you is the solution was to move those components out of the lightning namespace. So when you go to the open source repo, you will see that those components are no longer lightning dash button or lightning dash data table or whatever it happens to be. These are going to be c dash button or c dash card or whatever, right. So, we actually did the hard work of doing a surgery replace gotcha all across the entire repo. And we started just by doing okay, let’s just see if we can just replace all of the lightning with c…

Josh: I’m sure that worked the first time.

Greg: Yeah, no, I didn’t.  Not at all.  It went crashing and burning. Because then what we realized was, there are certain components that have dependencies tied to the lightning namespace, you know, back into the core mothership, if you will, right. So so we had to make some hard hard decisions and, and what that meant was you, I would love to give you all of the base components. But I currently am unable to because of those core dependence.

Josh: Framing that for a moment, we’ve taken some of the base components, we’ve pulled the metal lightning namespace, we’ve put them into the c namespace and allows you to have access to them. Now, there’s one thing to think about in working with these components. And that’s dependencies. And thinking about those dependencies comes in two ways. And one of them is just basically why you’re not getting all the components open source.

Greg: If you see something like lightning input, input is one of the ones that sadly, we were not able to open source because we have many, many, many dependencies on an accessibility library and some other things that belong to Salesforce that we can’t open source at the moment.

Josh: I mean, it’s it’s touching right up against the data layer.

Greg: Exactly right. And so so some of these things, we’ve got been able to open source, and we were not able to put them into the C namespace for you. So I can still use lightning dash input inside of my feed dash card. But what all that means is now your component will have to be running on the platform on the Salesforce platform for that input to actually work and be able to resolve itself and know what it’s supposed to do, because it’s going to call out to the lightning namespace.

Josh: As we’re talking about components here and what our components being will typically made out of other components. And so Greg notes that if you’re going to start digging around with the open source components, you should look to see what the other components are within it so that you know what’s going to come along for the ride. And the fact that you can mix and match between the open source components in the ones in the lightning namespaced. It has an impact on Greg’s job.

Greg: So good news is hey, I love all you guys out there embracing the components. But the bad news is, that means you’re going to start using them in ways that we might not have thought of and therefore you know, we need to address those use case scenarios. And maybe that impacts performance or whatever. It might be. So it is a learning process that we all are continually in together because we are, you know, we are all building this together, whether you believe that your contributions to the Salesforce ecosystem are big or small, you know, I can tell you they have an impact, because the sheer fact that you’re using a base component in one of your components means that now, you know, I need to be thinking of you when I make changes to any of these components. And you know, I will tell you, the hardest part of my job is absolutely 100% the fact that we are committed to never breaking you. And this was when I took over as the the product manager that was my manager at the time. That was the first thing he said to me, he said now just remember, in every decision that you make from here on out, there is a piece of knowledge that needs to be central in your decision making process and that is you cannot break anyone. And I tell you what, that is a rough tightrope to walk because you want to do the best. You want to add functionality, you want to do new things. And yet you always have to be looking in the rearview mirror.

Josh: Yeah, you want to add, enhance and innovate and also not break anything.

Greg: Exactly.

Josh: And that’s our show. Now, before we go, I did ask Greg, what is his favorite non-technical hobby is. And if you know him personally, it’s quite possible that you’ve received an invitation to it.

Greg: I live on a 45 foot sailing catamaran with my wife and our dog. And so we are not sales forcing because my wife is actually the engineering manager on SLDS. She wrote the first lines of CSS for the lightning design system. And so when we’re not Salesforce together, then we’re actually sailing together. So that is very definitely what I most enjoy.

Josh: Thanks for listening everybody. If you want to learn more about this podcast, head on over to developer.salesforce.com/podcast where you can see old episodes and also links to your favorite podcasts are I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.