Is there a way to add multiple classes using the renderers method?

Question

I'm trying to build a rather complex looking table, and i've been playing with various functionalities from handsontable.

One thing i was hoping to achieve is to have a cell be assigned diff classes for styling purposes. So im using the renderers for various scenarios. Thing is, when i assign the new class to the cell, is like is rendering it for the first time.

Example:

const cellClasses = (row, col, prop) => {
const cellProperties = {};
if (col === 2 || col === 8 || col === 15) {
    cellProperties.renderer = borderTest; // uses function directly
}
if ((row === 6 && col > 1) || (row === 12 && col > 1) || (row === 18 && col > 1)) {
    cellProperties.renderer = bgTest; // uses function directly
}
return cellProperties;

};

function bgTest(instance, td, row, col, prop, value, cellProperties) {
    Handsontable.renderers.TextRenderer.apply(this, arguments);
    td.className = 'testbg';
}

function borderTest(instance, td, row, col, prop, value, cellProperties) {
    Handsontable.renderers.TextRenderer.apply(this, arguments);
    td.className += 'testborder';
}

Please dont pay much attention to the logic. My concern at this point is that if a cell happen to meet both conditions, that it gets one class added to the other.

A hacky way would be for me to make an even bigger IF with a combination of both logics, but as my grid grows more complex, it will be much harder to maintain.

So, my question is, is there an easy way to assign multiple classes to cells, an not at the same time.

Answer 1

The short is that no, you can't assign classes the way you're describing because Handsontable purposely re-renders the entire cell on each iteration. There is good reason to do this, mainly to reduce state bugs.

It's not a bad idea to have more specific logic to determine all renderers needed for your columns so I would say it's reasonable (and not hacky!) to come up with logic to declaratively define your columns. You may want to think about using something other than col indexes to make the code more scalable. In our tables we tend to have column definitions stored in config files or created from our backend services. Hope that helps!