Table CellEvent API not Correct?

Short Summary:
event.cellColumn Id returns the label property instead of the id property.
The property that is actually useful is dataPath .

The API and documentation are wrong.

Long explanation:

It seems that the API for table/column is not correct. Specifically, the cellColumnId property of a TableCellEvent.
It returns a different property. But both the originally promised property, and the one actually given, are not useful anyways.

I am referencing the Table Column API documentation , along with the TableCellEvent .

I setup a very basic table for testing:

$w.onReady( function () {

$w( "#mytable" ).rows = []; 

$w( "#mytable" ).columns = [ 
    {    'id' :  'idCol0' ,  'dataPath' :  'title' ,     'label' :  '' ,     'type' :  'string' ,    'width' :  100     }, 
    {    'id' :  'idA' ,     'dataPath' :  'dataA' ,     'label' :  'A' ,    'type' :  'string' ,    'width' :  100     }, 
    {    'id' :  'idB' ,     'dataPath' :  'dataB' ,     'label' :  'B' ,    'type' :  'string' ,    'width' :  100     }, 
    {    'id' :  'idC' ,     'dataPath' :  'dataC' ,     'label' :  'C' ,    'type' :  'string' ,    'width' :  100     }, 

$w( "#mytable" ).rows = [ 
    {  'title' :  '1' ,  'dataA' :  'A1' ,   'dataB' :  'B1' ,   'dataC' :  'C1'    }, 
    {  'title' :  '2' ,  'dataA' :  'A2' ,   'dataB' :  'B2' ,   'dataC' :  'C2'    }, 
    {  'title' :  '3' ,  'dataA' :  'A3' ,   'dataB' :  'B3' ,   'dataC' :  'C3'    }, 

console.log(  'Initialized Table:' ); 
console.log( $w( "#mytable" ).rows ); 


After loading the page, everything is as expected:

Initialized Table:

title dataA dataB dataC

0 1 A1 B1 C1
1 2 A2 B2 C2
2 3 A3 B3 C3

Now I want to add some code so that when I click on one of those cells, it changes the value to ‘X’.

export function mytable_cellSelect(event) {

let ColId = event.cellColumnId;
let RowIndex = event.cellRowIndex;

console.log(  'User clicked table at:' ); 
console.log( ColId +  ', '  + (RowIndex+ 1 ) ); 

var rows = $w( ‘#mytable’ ).rows;

rows[RowIndex][ColId] =  'X' ; 

$w( '#mytable' ).rows = rows; 



I then click on cell B2:

User clicked table at:
B , 2

title dataA dataB dataC B

0 1 A1 B1 C1
1 2 A2 B2 C2 X
2 3 A3 B3 C3

Here we have a few problems.

The cellColumnId property of the event is returning ‘B’, which is actually the label property.
We can’t use the label property to modify the rows, as it’s looking for the dataPath for the array index.
Even if we did have the cellColumnId , there’s no direct way to access the array using that anyways? What’s the point?

The work around? Assign the same value to both dataPath and label .
Such as:
{ ‘id’ : ‘idB’ , ‘dataPath’ : ‘B’ , ‘label’ : ‘B’ , ‘type’ : ‘string’ , ‘width’ : 100 },

Then, ColumnId returns a label that is actually the dataPath . Makes perfect sense.

? ? ?

My question/concern is, will the ColumnId property be fixed in the future? If I use this work around, and then it started returning an actual ColumnId, will my code break?

OR, am I missing something completely?:grinning:

Seems I’m not alone. From a few years ago too…

event.cellColumnId : Is there a mistake in the documentation ?

Hi Derek,
Thanks for reporting this. I’ve notified the Velo Docs team and will report back as soon as I have an update.

1 Like

I have an update! The docs are correct, but unfortunately, the API itself is incorrect. We’ll create a ticket to have this bug fixed as soon as possible. Thanks again for letting us know.

Hi Marlowe,
Thanks for the response.

This brings up new questions.

  1. Is the API name to remain the same, while the functionality changes? As mentioned above, this means anybody using an existing work around will have their code broken.

  2. What purpose is the column id? The property we need to do anything useful is the columnIndex or dataPath. Even if the columnID is returned as the documentation intends, we’ll still have to use a similar work around.

@derekmoorer I don’t know. When the ticket is created, I’ll add your questions and keep you posted when I get a response. Unfortunately there is a long backlog of bugs for us to fix, so it will probably take a while. Thanks!

Thanks Marlowe.

For what it’s worth, my suggestion would be to:

  1. Leave the functionality of cellColumnId alone, and mark it as deprecated.

  2. Create a new property called cellColumnIndex , which matches the functionality of the existing cellRowIndex .

Just my 2 cents. :slightly_smiling_face:

In the meantime, anybody looking to use a work around with unknown functionality ahead, I’d suggest just setting all 3 fields to the same value (id/dataPath/label) if you can.

@derekmoorer Hi again, this issue should now be resolved, and the API functionality should match the docs. Can you please check and let us know? Thanks!

Hi @marlowe-shaeffer

Well, that may explain something that @yisrael-wix has been looking into in a separate thread, here:

Briefly, 5 days ago I noticed that event.cellColumnId had started to behave differently from when the site that I have been working on was tested. It may have started to get up to tricks a few days before that (it’s a low traffic site and the affected pages have only just been launched). On the published site where previously it returned something like Mon it now returns something like columnId_7f600ee7-c616-4484-8121-c931f34f0c99. Meanwhile, in preview mode it continues to return Mon .

However you cut it, I think the inconsistency between the previewed site and the live site counts as a bug.

I’ve coded round it, see referenced thread, and would deeply appreciate a nudge to let me know if/when I might have to code round the next iteration.

Whatever happens, please please please could $w ( “#mytable” ). columns [i]. id remain consistent with the value subsequently returned by event . cellColumnId??

While I’m here, are you the right person to ask where to look to find out what is likely to be “fixed” in the near future? I’d appreciate a bit of warning.

Hi Mike,
Thanks for letting us know about this issue—we’re looking into it. And, yes, I’m the right person to ask about it. I will update this thread once I have more information.

It sounds as if the below prediction became true?
If so - it’s really a poor idea to completely change functionality of an API that is already in use.

Please please in the future, consider depreciating an API rather than breaking legacy implementations.

Unpredictable changes to the functionality of an already published site is not professional.

@derekmoorer Thanks for your feedback. We will be reverting the change shortly and then introducing a new solution. I’ll keep you posted.

@derekmoorer I would second your suggestion of going with a cellColumnIndex. As you say, it keeps things symmetrical with cellRowIndex. Also it’s completely intuitive, and very straightforward to convert into label, dataPath, or anything else (optionally collected from the table definition on page load ).

By the way, @marlowe-shaeffer , while Wix is looking at tables there is another thing that might be worth considering - though it’s only a very small one. When a table is connected to data, the selected cell is highlighted. When a table is not connected to data the selected cell is not highlighted and there seems to be no way to highlight it.