Setting up ESLint with Google Standards and Salesforce LWC standards in VSCode

If you are part of a team of developers and want to ensure coding standards, ESLint is one of the easiest and most reliable ways to do so. The problem is, ESLint can be a bit of a pain to get working right. I have outlined the steps you need to take in order to start enforcing your coding standards without having to remember when to type 2 spaces or 4! Because no one really wants to spend any extra keystrokes on typing extra spaces. If you are not doing Lightning Web Component development on the Salesforce platform, you can skip the LWC standards part of these steps.

Step One… from your command line, in your project root type the following:

>npm init (Accept the defaults as you are guided through the prompts)

Step Two….

>npm install eslint –save-dev (this will set ESLint to your local directory)

Step Three…

./node_modules/.bin/eslint –init

(follow instructions, selecting appropriately and finally selecting Google for style)

Step Four….

npm install eslint @salesforce/eslint-config-lwc –save-dev

Step Five…

In `.eslintrc.json` (in project root), paste the following:

{

  “extends”: [“@salesforce/eslint-config-lwc/recommended”,”google”]

}

If you are lucky and you don’t have a global install of the same modules, ESLint may be working perfectly for you at this point… e.g. your JS files now look like one giant error… yay!

If you are normal, and you have a mix of global and local ESLint installs going on, follow the next steps to clean up your project and make the angry ESLint error at the bottom of your screen go away….

*if ESLInt is throwing an error due to the module path not found, go to Preferences ==> Settings ==> Workspace ==> Extensions ==> ESLint ==> ESLint: Node Path 

Edit the file to point to your local config i.e. if it looks like this (global):

 “eslint.nodePath”: “homepath/.vscode/extensions/salesforce.salesforcedx-vscode-lwc-46.10.0/node_modules”,

Change it to the relative to your machine version of this:

“eslint.nodePath”: “homepath/git/myDirectory/force-app/main/default/lwc/.eslintrc.json”

Now make sure your file associations for JS files is set to use ESLint and auto format on save and you are off to the races!

For more information on the modules I am using here see:

https://www.npmjs.com/package/eslint-config-google

and…

npmjs.com/package/@salesforce/eslint-config-lwc

Happy coding!

UI Developers really can design… even without HiFi mockups!

Our human minds love to put things into boxes. We strive to categorize, organize and streamline. In the development process, we have attempted to break the steps of creating software into “logical” parts as though the dev team where musicians in an orchestra that could be arranged in an ideal manner to best suit the conductor. Having been part of many teams where this categorization occurs, I can say safely that this approach is destined for disaster.

Why am I cynical about an approach that has thousands of books, articles, and manifestos touting its glory? I am cynical because in my own experience, categorizing people is a limiting approach to empowering creativity. I think as developers, there is an expectation that harkens back to the days of the mainframe computer that we are not interested in how things look nor should we have much by way of opinions about the matter. That is total hogwash. I am not alone, even if I may be unique, in being extremely aesthetically driven and opinionated as an engineer. Separating design from the front end development process is like separating taste from cooking or textiles from fashion. You just cannot do it and still have a cohesive product. At best you have introduced a layer of unnecessary bureaucracy.

This is not to say that we should not have flows which will determine the user experience or low fidelity mock ups which allow stake holders to grok what the product team is suggesting for a solution. What I am against, is the predetermining of every visual aspect of a feature by UX designers and then handing said blueprints off to the UI dev. What we have just done, is add a layer of complexity. A great, or even good, UI developer can take low rez. mock ups and given a set of UX patterns (already decided upon by the company or product team) rapidly build a working prototype that then can be handed back to the stakeholders for sign-off.

Why would you not do this? In our new process, we have now two steps to iterate upon rather than one. Here is how it goes in our divided system… HiFi mocks are iterated upon with product, UX designer, and stakeholders. Everyone is happy, UX designer hands mocks to UI developer. UI developer goes and churns out the feature to spec. hopefully everything makes sense from a programmatic standpoint. If it doesn’t make sense, UI dev has to reach out to UX designer who then reaches out to stakeholder/product for confirmation of change, UX designer iterates on their own design and hands it back to UI dev again. UI dev continues and when finished presents to stakeholders for walkthrough. Stakeholders find an issue or something that isn’t quite right now there is real data in the application. And…. rinse and repeat, the process starts over again.

The thing is, creativity is seen as something that stands on its own and is not in the realm of the analytical. This is a societal issue, not just a corporate one. We are more comfortable with the idea that one type of person is good at x while another is good at y. It creates a sense of security for us when every part of product development can be labeled, assigned and allocated in a safe little bite-size piece. That way if anything ever goes wrong, we can point to the piece and fix it just there! NO! Silly nonsense. Process is amazing, I love process and order. But like in nature, order and process must evolve out of necessity. They cannot be overlain like a scaffolding that will solve all of your problems. The problems must themselves be addressed and then the process will follow. At the end of the day, the dissection of the development process makes the work a lot less engaging and a lot less fun. Ironically, by trying to eliminate ambiguity and surprise, we have introduced complexity and redundancy.

Lightning DataTables Issues…. read this before you use this base component!

I was really excited to use the new Lightning DataTables Component with the release of Winter 18. I have implemented them in a new project that needs to be functional on mobile and desktop. As the LDS (lightning design system) and LEX (lightning experience) are mobile first, responsive UX frameworks I assumed the UX would be seamless on both desktop and mobile. I was wrong and it was not until after I opened a case with SFDC and 2 weeks of back and forth that I get an answer from the SFDC tier 3 support stating that the DataTables are not mobile ready because they are leveraging the LDS. Now, first off I am not accepting this answer because I have used LDS to style tables that work swimmingly on mobile. I have said as much to the ticket owner at SFDC and will see what they say. To give a description of the problem—

When the user scrolls on mobile the header row disappears or partially disappears… it comes back if you tap it but then disappears again when you scroll. This is not the only issue I have fount with the DataTable component.

  • Sort is weird… it sorts alright but once you sort one column the next column you sort seems to be dependent on the initially sorted column.
  • Column sizing turned on seems to break the responsive table.
  • Of course the aforementioned header on mobile issue.

If I had known these things I would have rolled my own table because another big limitation (that I did know up front) is that DataTables does not allow for input elements.

 

Exciting New Base Components With Winter 18!

Here is a list of new and changed Lightning Components for Winter 18. I am really excited about the dueling picklist, the native slider (hopefully it is mobile friendly) and the added notifications library!

https://releasenotes.docs.salesforce.com/en-us/winter18/release-notes/rn_lc_components.htm

Keep up the good work SFDC Lightning Product Team!!

Handling Server Errors in Lightning Components

The communication between Lightning Components and Apex can at first seem a little unwieldy when compared to the close coupling between Apex and Visualforce.

With a little coaxing and massaging however, Apex can be brought to obey your beautiful Lightning stylings even when it throws a nasty exception. I found myself frustrated by the murky handling of errors in my try — catch blocks at first. That was until I discovered the beauty of throw new AuraHandledException()!

I had already wired up my modal to let the user know their query had returned no data but until discovery of the AuraHandledException I was not finding a friendly way to insert the likes of callout errors (500, 400, etc) into my pretty modal. I guess I should not have been surprised when throw new AuraHandledException() did exactly what it said it did! In my data handling helper I was already trying to catch the error in the response but because my errors were unhandled they were creating those ugly red Lightning error pop-ups generated by the system.

Turn this:

Into this:

The code below is not a complete implementation but is intended to give you a sense of the important parts which are:

1. In your try – catch block on your server call use throw new AuraHandledException()!

2. Wherever you are processing your response, in my case the FetchDataHelper handle your error by passing it to your display prompt/modal.

3. I am creating a modal dynamically in the parent component, the dataDisplayHelper creates the modal with the appropriate error. Credit to Mike Topalovich for the modal code(not included) and the dataFetch code!. You can find lots of examples online for modal creation — it is fairly straightforward.

4. Ultimately what you end up with is graceful error handling which makes your users happy and not stressed out by your application. Also, it makes troubleshooting much friendlier should someone log a defect (and hopefully add a screenshot) after you go to production…. that never happens.

Dynamic Input Field Lightning Component

For a project I am currently working on I wanted to implement a dynamic input field that set it’s body based on the user’s selection of the type of query they are making. There are 6 possible fields the user can query on and these 6 fields can be mapped to 3 types of queries — Date Picker, Date Rage and Input Text. Using what I have learned in dev 601 with Mike Topalovich (kudos again to Mike), I have been actively pairing down and generic-izing (?) every component I build. So this solution needed to be both generic to the given situation and also flexible enough to accommodate the variety of options needed. I ended up creating a simple component to hold the dynamic input field which has optional parameters of “name” and “dynamicSetting”. I wasn’t able to pass the change value to the dynamicSetting on the created component so I have an attribute in the parent that controls the colored label showing the value of the date slider. This is also the value that would be passed to the APEX controller to execute the query.

The main controller passes the value from the onclick event to the helper and runs through a Switch statement mapping the type to the proper input field body. Then the helper sets the body of the dynamic input field accordingly. I declare the dynamicInputField.cmp as a dependency when I load the parent component to avoid trips to the server. I am pretty happy with the result and my only ToDo is minimize the code within the Switch statement to reduce what feels like duplicative javascript. Here are the views of the 3 possible input fields:

Why Lightning is Making Salesforce Even Better For Developers & Admins

I have been developing with the SFDC platform for several years. In this time I have surmounted many a learning curve and devised copious work arounds for dead ends that I have run into because of system limitations. These challenges have been exciting to overcome but have often meant adding code that I knew I would one day be back to refactor. Salesforce has been sold as a clicks not code development platform but as anyone who has implemented SFDC knows there is a limit to where configuration alone can take you. I think this has created divisions between admins and developers. There has not been until now, a way to handoff your beautifully written and toiled over code solutions to your admin wizard friends. Along came Lightning and everything changes…

Adoption is still low because so many users are married to their Classic UI and are not inclined to invest in making the switch or are not sure where to begin. I think that Lightning adoption will grow as more developers understand the power of the framework. I am taking the Dev 601 course this week with Mike Topalovich. Although I have been building some Lightning Components over the past few months, I am finding lots of good nuggets that I have not yet discovered in this training. Kudos to Mike for his depth of knowledge on this subject and for keeping some levity through the tech talk!

Here are some of my favorite learnings so far:

  • Components are your lego blocks… developing with SFDC is now modular by design!
  • <Lightning:layout> component gives you the Grid for free! Crowds go wild… especially those who have toiled over SLDS styling for days….
  • <aura:if> is magical…. I can see use cases with this involving custom component configuration by admins.
  • Expose your components for use by your Admin friends and make them configurable by adding a Design Resource
  • LEX is still a work in progress but there is something special about the SFDC developer community…. (just look at StackOverflow if you don’t believe me) I know that the innovation of folks working with SFDC LEX will grow exponentially now that we have just been given this awesome new set of tools for our toolkit!
  • Javascript, Javascript everywhere…. If you are a JS dork like I am, this is just great news.

….More to come!

 

Human and Able

The engineer at Google who wrote the sexist manifesto about why people without a Y chromosome are less fit for technical jobs is unfortunately, not alone in his small-mindedness. All humans who are not white males —that fit into one of the desired buckets for what white maleness should look like in America— are aware that there are people around us with hate in their hearts and smallness in their heads. The problem is that in the past year the conversation has been brought to the fore as certain political factions and certain former reality tv stars have taken over a certain house that is white and also near to Delaware… read between the lines folks. There are some who might argue that it is healthy to bring the discussion to light. I would argue that you should leave that pimple alone and let the puss stay where it is otherwise you might end up with an ugly scar. Hate, racism and bigotry are facets of our animalistic-lizard-brain tendency toward tribalism and have always been floating around in the hearts and minds of human beings. The trigger for activating the small-mindedness can be anything from rejection, repressed sexuality, or just simple ignorance. To argue that we should allow ourselves to indulge these base and lesser instincts is to suggest that we should plunge ourselves back into the pages of ancient history. We have come far but we must actively ensure that our progress is guarded and tended otherwise the weeds will encroach and the crop will be spoiled. Civility is not just burying, it is not about political correctness or liberal elitism. Civility is about knowing that one’s own opinion is not the truth and maintaining an openness to others because it is good for them and good for ourselves and ultimately good for humanity when we create space for diverse thought and education. Free speech is not the same as hate speech. Having a conversation about diversity does not mean spewing your poisoned inner workings to the world. Most importantly, dialogue that encourages diversity must come from a place of love and not from fear.

Maker Fun

I seem to always find out about contests when they are over or a day away from being over… I subscribe to a great site called Instructables and I just found their contest page. If anyone has some free time and wants to submit projects or ideas, there are a bunch of contests to choose from. It looks like some of them repeat yearly so could be an opportunity to plan a project and get a team together for next year…

http://www.instructables.com/contest/

They even have a fidget spinner contest, bored tween/teen anyone?

Summer Camp

Resources for learning online have exploded in number over the past five years. Many of these resources come with a moderate to hefty price tag, eg. Lynda.com or Pluralsight. I will not argue the merit of these subscription learning platforms as I have found their paid content to be valuable —particularly in the case of Lynda as they have free classes but their paid classes include resource files. There are however, many free options that may require a little more setup or self directed research by the user but are akin to the open source version of learning online. Salesforce has Trailhead, a learning platform packed with options and even badges that you can earn to display on your social media profile. The list is long and I don’t only consider the traditional tutorial platforms to be online learning. StackExchange is my personal learning trove. I am usually learning on the go, mid project as I need to understand a tool in a deeper way. StackExchange is perfect for this kind of learning as it is peer to peer but the FCC can’t shut it down because no music companies are being harmed in this trade 🙂

Here is a list for those curious about where to start:

71 of The Best Places to Learn to Code For Free