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.

 

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.