1

I have just implemented the Winter '18 Lightning DataTable Component in a project set to go live early next year. I have a love hate relationship with this base component here are my issues, and I am answering this question with my findings in hopes it will save others some head-aching.

  1. Why does the header row behave weirdly in SF1? You won't see this in the Chrome emulator but fire up the app in your IPad for some odd behavior.

  2. Why no input elements? Read-only sadness.

  3. I got lost in sort... the documentation failed me here completely and I had to dissect the component behavior to understand how to fix it. Sort just didn't work initially. The docs are confusing on where to set the attributes... i.e. at the component level or the data column level.

  4. Setting column initial, min and max sizing at the data level as the docs suggest made the resizing of columns break.

  5. Wasn't getting the click row data initially.

3
  1. In SF1 the header row behaves really strangely, it disappears when you scroll, and reappears sometimes only in part when you tap on it. 1a. I logged a case with SFDC and eventually was told the problem is that DataTables are using LDS which isn't supported in SF1. I think this is a bogus answer as I have constructed my own tables using LDS which work swimmingly in SF1.

  2. No Input element yet, this is in the docs but it is a serious agro.

  3. The sort function needs some tweaking to work properly. If you copy the documented code you will find it does not work correctly. I added an attribute for SortedDirection and set the default to Desc as well as an attribute for the sortedBy. See below:

    <aura:attribute name="sortedBy" type="String" />`
    
    <aura:attribute name="sortedDirection" type="String" default="Desc"/>`
    

    3a. Sort is still a little weird after this as there seems to be a dependency on between the columns, for example, once you sort by name if you sort by age the age sort will be sub sorted within the alpha sort of name. It might be better to roll your own sort function if you want sorting on multiple columns.

  4. Don't set the initial width, min and max width of the columns because you will get wacky results with dynamic data and the column resizing won't behave properly.

  5. Checkboxes are a little wonky but once you get used to their special logic they make sense mostly... don't add an onclick handler as the onrowselection handler does the lifting here.

  • Has the resizing of columns been solved yet? I ran across this issue in my org where I have 12 columns and the table cannot seem to handle that many. Even if I set the attributes, it ignores them and squeezes them together no matter what. I can resize them manually. Why even have the horizontal scroll bar if it can't handle the extra width? Also, there is an open issue here: success.salesforce.com/issues_view?id=a1p3A0000018C5BQAU – Chance Mar 28 '18 at 16:27
  • So interesting discovery as I have worked with this component more... Here are my learnings... If you use a javascript number (initialWidth: 275) as the column initial, min and max width you can set the width of the columns but the table will not be responsive. If you set a string value for those widths (initialWidth: '275px'), the table will be fixed width meaning it will be responsive but all columns will be the same width. I have preferred the second option and setting the column min and max with css using !important. Also do not set style="" on the component, it will prevent packaging. – binaryLady Mar 28 '18 at 19:13
0

Did you consider using 3rd party components? Appiphony is one of the biggest open source lightning component providers and their Strike Libary contains a lot of useful stuff. They are enhancing all their components on almost a monthly basis and it's all on github, so you can also contribute enhancements and profit from other contributions.

We are using it a lot and they are having a very useful data grid, where you can pass in custom components or just standard components (such as inputs). It seems like you could fix most of your issues with just passing your own "Cell" components to the grid, that know how to display and handle all your needs.

Check out their documentation here Strike Data Grid

  • 2
    I have used 3rd party components including Strike but they come with a lot of extra code. It is best practice to use 'out of the box' components where applicable and for us developers to embrace SFDC's core lightning components both so we can help them to improve the product by finding these issues and also to keep our applications as lightweight as possible. I do like Strike and Apiphony but as SFDC improves LEX I see less need to use 3rd party libs. These have been great tools for the early stages of Lightning and are also very helpful still when employing LDS in Visualforce. – binaryLady Nov 30 '17 at 18:32
  • sure, I'm totally with you! But in your case, it sounds like there are too many things that don't work so far (same as for us) with standard components. So I thought it might be worth sharing an alternative. Good to hear it was part of your considerations already :) – Basti Nov 30 '17 at 18:36
  • Yes, you are right Basti... quite a few unknowns in this component — hence my post here! I have had success with using Aura:iteration to generate dynamic tables using LDS which gives greater flexibility than the dataTables component and without the bugs! I am hoping SFDC will fix this component. I would recommend Apiphony and Strike to devs not wanting to mess around with LDS but needing components missing from LEX currently :) – binaryLady Nov 30 '17 at 19:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.