Answers

• allan Posts: 63,516Questions: 1Answers: 10,472 Site admin

  August 18

  No that isn't intentional and I'm rather suprised that it is happening like that. I'll dig into what is going wrong there when I get back into the office tomorrow and report back. Thanks for the test case.

  Allan
• osheros Posts: 4Questions: 2Answers: 0

  August 19

  The classes do get added to the TDs but not until after createdRow is called, suggesting it's called too early or the row variable doesn't contain the updated version of the row.
• allan Posts: 63,516Questions: 1Answers: 10,472 Site admin

  August 20

  Just been looking at this and now recall what is going on. I grouped the addition of cell classes into the draw function. The reason for that was the addition of a data type based class name. The data type might not be known until just before the draw, so it needs to be added there and I figured that it would make sense to do all the cell classes together.

  I could move the column defined class back to the cell initialisation if this is going to be a big problem for you. The other option is to use rowCallback rather than createdRow. Same idea, but it gets called on every draw, rather than just once.

  Allan
• tonykramer Posts: 2Questions: 0Answers: 0

  August 29 edited August 29

  @allan

  This is a breaking change that should be documented. I spent several hours trying to track down why my conditional event binding to columns (based on class names) was not working. Using rowCallback is not an option because you then end up with the events being bound multiple times (unless you store the event handler function and unbind it then re-bind it with each rowCallback call, which is really hacky).

  Unfortunately, I now have to resort to using column indexes to ignore specific columns when binding click events to the row columns, which will be a maintence nightmare if the columns get modified in the future.

  It would be really nice if the classes were added back in for this function so that things such as this are possible:

  {
    ...
    createdRow: (row) => row.querySelectorAll("td:not(.my-ignore-class)").forEach(...)
    ...
  }
  
• tonykramer Posts: 2Questions: 0Answers: 0

  August 29

  FYI for anyone else that comes across this, after playing around a bit more, I did discover a fairly trivial work-around that doesn't require you to use column indexes. Basically, you specify a createdCell function for the cell and manually add your class names there rather than using the className option.

  Example:

  {
    ...
    columns: [
      ...
      {
          ...
          createdCell: cell => cell.className = "my-ignore-class"
          ...
      },
      ...
    ],
    createdRow: row => row.querySelectorAll("td:not(.my-ignore-class)").forEach(...),
    ...
  }
  
• allan Posts: 63,516Questions: 1Answers: 10,472 Site admin

  August 30

  I've committed a fix to address this issue. It will be in the next release, which I expect to be later today

  Allan