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.
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 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?
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().
Context Contamination
A column-specific class requires the entire table API just to reference its own column - this seems architecturally inconsistent
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)
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.
Answers
table()is a top level method - it is not a child ofcolumn(), 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
@allan so what's a better way to get the table if I have a column? Without altering the column context for sure.
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
@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?
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 calltable().Allan
@allan, examining the ColumnControl constructor, it's a similar to my code:
constructor(dt: Api, columnIdx: number, opts: IConfig)This pattern raises concerns because:
Context Contamination
A column-specific class requires the entire table API just to reference its own column - this seems architecturally inconsistent
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)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 buttonsorder(). 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).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.
It was very much a conscious decision which I believe was the correct one and appears to be working well thus far.
Allan