Why does column.table() call change the column context?

amalnev

When you have a column stored in a variable like:

const column = api.column(1)

and then call #table method on it like:

column.table()

your column context is altered

https://live.datatables.net/yabiropo/1

allan

table() is a top level method - it is not a child of column(), so this is fully expected and correct in how the DataTables API works. When you call a top level method will to change the context to that method's return object.

Allan

amalnev

@allan so what's a better way to get the table if I have a column? Without altering the column context for sure.

allan

Can you explain what your goal is? I will hopefully be able to help come up with an answer.

To answer your specific question, you can't get the table() and retain the column context - that isn't how the API works. However, I'm sure there will be a way to do whatever you ultimately need to do, but I don't know what your end goal is?

Allan

amalnev

@allan My function only receives a column object - it doesn't know anything about the parent table. But I need to access a custom API that's attached to the table, like Api.register("table().customMethod()"). I assumed I could get the table context from the column to reach this API.

I came up with the only workaround:
const table = column.column(column.index()).table();

The custom api is related to a table, not to a column. Should I register the same method for the column anyway instead?

allan

If the custom API doesn't need any column information, what is the problem with the context changing to the table?

with that API method you would be able to do api.column(1).table().customMethod(), but the column information is discarded as soon as you call table().

Allan

amalnev

@allan, examining the ColumnControl constructor, it's a similar to my code:

constructor(dt: Api, columnIdx: number, opts: IConfig)

This pattern raises concerns because:

1. Context Contamination
   A column-specific class requires the entire table API just to reference its own column - this seems architecturally inconsistent

2. Hidden Dependency
   Storing dt + index rather than a direct column reference creates a subtle context dependency:
   this.column = dt.column(columnIdx);

My core question now: was this design chosen because of technical constraints in DataTables' API (since that context altering), or was it a conscious architectural decision?

I wish we had it like:
constructor(column: Api, opts: IConfig)

allan

A column-specific class requires the entire table API just to reference its own column - this seems architecturally inconsistent

It hasn't been a problem so far, and it needs to be able to access global operations such as draw() and in the case of the ordering buttons order(). Yes, it is open to misuse / mistakes by a developer, but that's on them. I also had ideas that it might be possible to do multi-column actions (e.g. from a colspan header).

Storing dt + index rather than a direct column reference creates a subtle context dependency

The column index can change due to column reordering, which is one of the things that any "content types" for ColumnControl needs to keep in mind.

My core question now: was this design chosen because of technical constraints in DataTables' API (since that context altering), or was it a conscious architectural decision?

It was very much a conscious decision which I believe was the correct one and appears to be working well thus far.

Allan