So recently, I started diving into lightning web components, and it was quite an experience from everything I have gathered from learning on Trailhead and attempting to build things on my own. Here are a few beginner tips I learned along the way of building some Lightning Web Components.

One of the first things you have to do is get your VisualStudio code set up correctly. Salesforce has created a few tools for you to install to use with VisualStudio code. Now I know you might be a Coda 2 or an Atom editor fan. However, setting up and installing these tools makes your life easier for deploying Salesforce Lightning Web Components.

With every framework such as Bootstrap, Materialize, and UI Kit there are rules you have to follow with specific guideline standards.  As I was building and going through Trailhead I would always keep the SLDS system open in a tab for easy and quick reference. When I was building for example a card, why would pick a card without actions over a card with actions? Well one is for viewing data and the other is for creating data within that card.  I always tried to go back and forth and learn what type of actions and components are already built. There is no need to build from the ground up if the system is in place for you.

As with being a UX developer I always check the column sizes and see how they outline using grids and column rows with spacing in between them because the thing I have seen on some of the lightning web components people have built is spacing is very wrong. Such as for example, the grid is set to 6 but the card within this grid isn’t set and instead they are using a styling of 80% instead of setting the component to have a column width of 5. Or I have seen people not use columns at all and just stick to using percentage sizes and media query calls to get it to look good and be responsive. The column system is similar to bootstrap no need to rebuild the system if the system is there for you to use.

This was something I learned very very very quickly. You need to watch and remember your naming conventions very carefully particularly when working on your trails. I had completed the Aura component trail which had me create a Hello World app with aura components through the developer console. Now when pushing a lightning web component in Visual Studio that was also named Hello World, I would be met with the words “Deploy Failed”. Why did it fail? Well I learned after much digging you cannot have any Aura components named the same as Lightning Web Components. When I was starting out, I assumed that because Lightning Web Components and Aura Components are on two different systems that I could maybe have two components named the same thing, especially in migrating an aura component to Lightning Web Components. That does not appear to be the case, so be sure to watch your names.

Now I know there are some companies that use other form factors of naming conventions and thats good, but you must stick to those naming conventions. For example if you are building a dashboard, don’t just call it dashboard call it “tellerDashboard”. And the components within that dashboard stick to naming each item with “tellerDashboardCalculator”. I am very happy Trailhead tries to nail this down by sticking to the same type of naming convention because I have seen many times where components are called “vague name-here” then the next item is called “other_Vague_Name”. It can cause confusion and when you are having to call components, stick to leaving it one way.

When building components, the first thing you want to do after you build a component through VisualStudio Code is to set up the targets of where these components are going to live. I let this slip by when I was building my own and when I deployed it to Salesforce it wasn’t showing up. I was lost for a minute. My code isn’t returning errors. The terminal said it deployed successfully to my org so what is going on??? It was then after checking my files that I had forgotten to change the .xml file to include the targets. Because of this, I have started making this the first thing I do when building a component that will appear within my Salesforce org.

It goes without saying that you should try to comment to help you remember months from now when you are having to update a component. Comments help the next developer pick up your work and understand the who, what, where and why of your code. You don’t want to be that developer that builds something they only understand and no one else does and then your past could come back to haunt you when a team has to scrape everything you built and people label you a bad developer for building some obscure code.

I know, doing anything in the terminal can seem scary especially since it requires a lot of memorizations of commands that you might not know off the top of your heads and that is ok. What I do since I can’t remember the 300 commands that might be required is I actually make a note pad that has all the terminal commands needed for said project. It is totally ok for you to make something to help you remember. Work smart not hard. Also when you don’t remember a command or can’t find one just remember the most important command within visual studio. Now one thing I get asked is if I prefer the terminal console vs the one in visual studio code and I prefer the one in visual studio code cause I don’t need to keep track of multiple commands and finding folders and remembering where I am at times and in some cases typing into the wrong terminal which has happened when I have multiple projects open.

SFDX HELP

Also this might be hard to believe but when building lightning web components, the inspector and web console can aid you in building your components. Cause you are able to debug them and see what exactly is happening such as when your data is not returning and is giving a null value. Or if you have a weird column error in your grid then you are able to fully inspect and seeing if there is a percentage is off.

Building lightning web components has definitely been an experience, setting up a dev org and deploying ideas to it. As I am building more and more. The more issues I run into, I will definitely be posting about. I might even publish a few tools and ideas I have if the occasion calls for it. Until next time developers.