Prototyping Lightning Component, SFDX, LTS and Travis
I have built a prototyping project—and saved in Github repo—to demonstrate how to:
- Create Lightning Components
- Unit testing Lightning Components
- Use SFDX to scaffold project structure
- Wire everything up in Travis—A SaaS Continuous Integration service
In this post series—2 articles in a row, I am gonna use this project to break these knowledge points down and dig into them. This blog post is the first article of the two.
What we’ll do in this article:
- Go through the mindmap for the prototyping project (most important!)
- Study recommended trailheads to learn Lightning Component
- Organize the project with SFDX style
- Collect some dummy user requirements and implement them
- List down the remaning topics for article 2
The source code stored in my prototyping project is merely the final version of the work. It is more intriguing and useful to understand how I reached this final version. Thus a mindmap below tells the story.
Content in article 1
the project starts from this trailhead project: Build a Restaurant-Locator Lightning Component. It is the first blue box in the top-left corner.
I collected several piece of “user voice” from nearby colleagues by asking them “what would you like to have if you were the user of this locator app?” and implemented them with SFDX stle. They are blue box 2 and 3 in the flow.
Content in article 2
I create two dummy Lightning Component unit tests in LTS and wired everything up in Travis, a Saas Continous Integration service.
I’ll make a summary about pros and cons from my standing point of view.
Are you ready? let’s get the ball rolling now!
Study base project
Before going through my prototyping project, make sure you have done this trailhead project Build a Restaurant-Locator Lightning Component.
This trailhead project serves as a baseline for the following activities.
Collect user feedback
The trailhead project above is done in the Developer Console. Developer Console is good for quick and dirty test, rather than real life projects.
In this step, I started by re-creating all files by SFDX commands, such as create project, create lightning component file etc.
By doing so, the project file structure is re-arranged according to SFDX style. What’s more, using SFDX helps us to automate the deploying process and integrate to any Continous Integration system. This benefit will not be visible in steps of this article but the subsequent one where Continous Integration is discused.
Then I collected “user requirements” from fake users–i.e. colleagues close by. These are gathered requirements:
- “I definitely need a map for quick action!”
- “Clicking to show/hide details (in the restaurant in the list)”
- “List is OK, but data visualization is better”
- “I need Only high rated restaurants, and sorted for me”
- “Mobile first!”
Then these requirements are implemented in the prototying project. The information Architect diagram depicts the high level picture and data flow among components.
In order to see the details, refer to its code in Github repo, I also strongly suggest to install it into a scratch org—check the repo README file.
In the following article, we’ll do:
- Write Lightning Component unit tests
- Put everything into a Continuous Integration pipeline