Salesforce LWC Component Series — Part 2
Lightning Web Components Development — Step by Step approach
This story is a continuation of : Part 1
Requirement
To recap, the goal here is to create an LWC component and place it on the Home screen that shows the following information about the logged in User:
- Name
- Username
- Profile
Development Steps
The below steps will not be structured as a ‘copy-paste’ resource. But instead, I would like to delve into the thought process that goes into creating an LWC.
1. Decide the User Experience
Before writing any code, we need to have a plan or view of what needs to be shown on screen for the LWC. For this requirement, it doesn’t need to have any elaborate design. It may just need a header and fields on two columns — a rough sketch like below is all we need at this stage.
2. Create basic HTML structure
The first step when creating an LWC is to add the basic HTML structure for the LWC. This needs to be added to the file in VS Code with the extension type .html. As seen below, when the LWC is first created — it just has one tag called<template>
So, based on the rough sketch, we need a card like element which has a header and then should be able to place 4 fields within the card. A simple google search for the Salesforce documentation lead me to this page : https://developer.salesforce.com/docs/component-library/bundle/lightning-card/example
Here, there are examples provided of the different types of cards that can be created. I’m thinking of starting with a basic card without footer. So, I copy over the code from the example page and add it to my HTML file.
Now, a cool thing with VS Code and LWC development is that, it can be quickly deployed to the Org after each change and checked immediately how it looks. Therefore I deployed it to my connected Org. Now, I will try and add it to the Home Page. To do that, I simply select ‘Edit Page’ on the Home screen in Salesforce.
To my surprise, I can’t find the custom LWC in the App Builder page.
That reminded me — the way LWC can be distributed needs to be specified in the meta.xml file of the LWC. This is basically defining the components or locations in which the LWC can be placed — like it can be used in a Flow or a Lighting page etc. For a new LWC, this file looks like below:
Looking up Salesforce documentation for this lead me to page : https://developer.salesforce.com/docs/platform/lwc/guide/use-config-for-app-builder.html
On this page, there is a sample code available. I copy over the part where Home Page is mentioned and also ensure <isExposed> is set to true. Save and deploy to Org again.
Now, the LWC starts appearing in the App Builder.
Add it to the Home page -> Save and check how it looks. Voila!!! It appears — Oh but it has a ‘New’ button — which I had not noticed in the code 😀
I then go on to remove the New button from the HTML and deploy again to the Org. The LWC component now looks like this:
What I am trying to show here is : this is how most people do software development — unless you have a photographic memory and can remember every single syntax and is able to put it in the right place and in the right way on the first go itself. Probably no one does that. Anyone can learn coding — it is not rocket surgery.
3. Modify HTML according to design
Ok, coming back to our job at hand — I have now removed the button and need to start adding the fields. As I was on the Salesforce developer’s reference page for ‘cards’ — I look around there and see if there is anything listed like ‘field’ or ‘text’ or anything of that sort which can be used to display the data on the screen.
I click on a few of the options on the left side of the page and see how the examples looks like. I notice an option called ‘input’ which looks like a field on screen. I then copy over the sample code from there to my HTML and create additional fields using the same line of code.
And this is how it looks like now after deployment to the Org:
Ok — there are couple of immediate problems that I notice compared to my UI design. I had imagined the fields to be in 2 columns and also they should not be editable. May be I will leave the alignment this way for now — as it looks to have more space and may be easier to read rather than crowding them all together.
To make the inputs read-only, I refer back to the documentation and check under the section ‘Specification’.
I find out that a specification called read-onlycan be added to the HTML to make it non-editable. but I’m not sure how to add this to the HTML tag — so I look at some of the other examples in the related pages and notice the use of another specification called checked. So, I decide to add read-onlyin a similar way to the HTML tags.
I add this to all the input tags in HTML and re-deploy. The component looks like this now:
The fields have disappeared ? No — actually they are there — it’s just the border of the input that has disappeared and values will be shown. Will leave it as this for now.
You would have noticed by now that the software development process is very much an iterative process. In the above steps, I could have spend more time trying to get the fields into two columns or making sure the input’s border appears — but that’s for later after I ensure I can get the bare bones working with this approach. Because there’s always a possibility that I may hit a road block and may need to discard all of this work and start over with a different approach.
To be Continued…
Now that we have got enough UI elements to work with — the next step is to make this component get data from wherever it needs to and show it on screen. That’s for the next Part of this Story series……
