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.
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!
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.
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.
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.