Salesforce London Developer Meetup: January 31st
What better way to see January out than attending the first London Salesforce Developers’ Meetup of 2018? There was a great turnout, lovely food and drink and two great talks. Read on to find out more!
As usual, the meetup started with time for chit-chat over some food and drink. Thanks to the team at Slalom Consulting, these refreshments were a cut above. A highlight had to be the gin table with a choice of three different types of gin. Surely a meetup first. Fortunately a photo was taken for posterity!
Talk 1: Error Handling in Lightning Components
With a little snacking, sipping and networking complete it was time for the first talk of the evening: Richard Clark’s Error Handling in Lightning Components.
This was a fun and interactive talk with lots of little demos and interesting additions from the audience.
The impetus for Richard’s talk was that he had been researching best practices in error handling and found a gap: despite all the articles out there on the right ways to do error handling, none of them dealt with all types of error handling, server-side and client-side, in a single solution. After looking into it further, Richard didn’t find any magic bullet, but he had some essential lessons to share, plus good things may be coming in Spring 18.
We’re looking forward to the full video of this talk from Mobile Caddy (we’ll add the link here when it’s out!), but in the meantime here are a few great takeaways from Richard’s talk.
- Learn to debug before you start writing Lightning Components: This will pay dividends in the long-term. If you don’t know where to start, try Todd Halfpenny’s talk, Browser Dev Tool Debugging like a Unicorn-Ninja-Cat-Rockstar.
- Validation is two-step: We need to show the user which fields are required using the Lightning Component markup, but we should also ensure they can’t save a record with invalid values. There are 2 ways of doing this:
- For Lightning namespace components, this is much easier to handle and you can validate all your inputs in a single call if you use a common aura:id.
- Create a custom reusable error message component: It’s a good idea to write your own custom error component that you can use on all your Lightning apps. This will allow you to define some standard behaviour, such as deciding how to display errors depending on whether the component is in mobile, Visualforce or Lightning Experience, and then enforce it for all developers. This can be directly integrated, or you can use a Custom Event to fire notifications to your component for it to display the relevant information. (Just note that, if you have your component used in multiple other components on a page, you’ll need to provide unique IDs so that your messages don’t appear in every component! This can be an attribute of your Error Handler component.)
Slides from my talk last night at the London Salesforce Developers User Group on Lightning Component Error Handling. Video recording should be out soon! https://t.co/tHVINlAQbc— Richard Clark (@RichClark808) February 1, 2018
Learn more about testing Custom Lightning Components
Richard is hosting a webinar in a few weeks’ time where he’ll discuss his Lightning findings in a testing context. He’ll discuss the key features of Lightning development with best practices for effective testing.
In this webinar you will learn:
- How to build reliable tests in the Salesforce Lightning Experience
- How to make tests reusable across Lightning and Classic
- How to test custom Lightning development achieved through Configuration (Flexipages) and Code (Lightning Components)
Click here to register for the webinar.
Talk 2: Genius Dashboards in Einstein Analytics
The evening’s second speaker was Rikke Hovgaard was on building good dashboards in Einstein Analytics. This was an informative and interactive talk, which Rikke is going to be delivering in full at the London’s Calling 2018 community event this month.
In the talk, Rikke gave some interesting principles of good dashboard UI design based on her experience of what works for users. (A great tip was that, if her grandma can’t understand it, it needs to be simpler!) While we don’t all have access to Rikke’s grandma, this can be transferred easily to your own working environment. Showing a colleague your dashboard to see if they can understand it easily is a great way to find out what works and what needs improvement.
Rikke’s talk had three main topics, which she’s also talked a little about on Salesforce Blogger:
You can use the links above to read about each topic in more detail. There were some great takeaways from the overall talk which can apply to any dashboards, not just Einstein Analytics.
- Tailor your dashboard to your audience: is it for a manager or a sales rep? This will determine whether you need to show an overview of a data or an individual’s target performance, for example.
- Describe with text what the user is seeing. You can help understanding by using clear headings for the overall dashboard, as well as on each illustration or widget.
- Describe predefined criteria, such as ‘closed opportunities’ or ‘open opportunities’. Make sure you also include any measurements used. For example, is the temperature in Fahrenheit or Celsius?
- Finally, keep the dashboard consistent: try to keep a similar layout between dashboards, and don’t move things around just for the sake of it – your users have learnt to read it, they don’t want to have to re-learn it!
With both talks complete, it was time for one last drink before heading home (or to the pub.) Cheers!