Why are we catching this exception and dropping it? If we get to this state something bad has happened and the user should know about it.

Here is my plan:
When a KeyError is caught, the current implementation does the following:

1. Notifies the user: It sets self._error_message to a user-friendly message like "Column '...' not found.". The frontend will then display this error.
2. Reverts to unsorted: It resets self.sort_column = "".
3. Displays the unsorted table: The function then continues, but since sort_column is now empty, it fetches and displays the data in its original, unsorted order.

Not all data types are sortable. See the orderable property in our dtypes.

We should not add the handler or arrow to columns that we can't sort.

Here is the plan:

1. Display a dot (●) indicator for all sortable columns by default
2. Allow users to cycle through three states: unsorted (●) → ascending (▲) → descending (▼) → unsorted (●)
3. Only show sorting UI for columns with orderable data types

Have we considered having multiple columns as a possibility? I think a single column is a good starting point, but I think it's an alternative worth considering, especially when a particular column contains lots of duplicate values, like a "date" column.

I agree that multi-column sorting is particularly valuable when a column has many duplicate values. I would like to get the single column sorting checked in first as a PR. Then check in a second PR for multi-column sorting. This current PR is already complex enough. I prefer two separate PRs as enhancements.

Yes, separate PR makes sense to me, thanks.

I can guess based on context what these mean, but I think a frozen dataclass would be much easier to understand at a glance.

We should iterate through dtypes directly to get both the type and the column name in one call.

Calling.dtypes for each iteration is making this into an O(n^2) algorithm. The n could be as large as 10,000, where that would definitely make a difference, though I imagine our widget would break well before then.

Aside: could you file an issue to check our limitations on the number of columns from a ux perspective? I imagine we'll need to solve that at some point soon-ish.

Complexity is reduced based on the suggestion
filed b/462525985 as TODO

I'm afraid of this. KeyError is a relatively common error in Python. Just looking at this code, it's not clear to me that this would always be the case of a missing column. Please check for the column presence explicitly, instead.

It should trigger this error to be honest. The user only allows the click on a sortable column name to trigger this part of code. Theoretically, we do not even need to catch this bug, because this exception should never be hit in our design. I will remove this try catch block.

This is quite a bit of logic. I would like to get JavaScript-level unit tests setup before merging this PR.

I've set up a comprehensive JavaScript unit testing environment and implemented tests for theTableWidget's interactive sorting functionality.

Testing Framework & Environment:
*Jest: Chosen as the primary testing framework due to its all-in-one nature (runner, assertion library, mocking) and strong community support.
*JSDOM: Utilized within Jest to simulate a browser environment, enabling DOM manipulation and event handling within Node.js.
*Babel: Configured to transpile modern JavaScript (ES modules) used in the widget and tests, ensuring compatibility.

Test Coverage: Thetable_widget.test.js file now includes unit tests that verify:
* The basic DOM structure generated by the widget.
* The interaction logic for column header clicks, including:
* Initiating ascending sort on the first click.
* Reversing to descending sort on the second click.
* Clearing the sort (returning to unsorted state) on the third click.
* The correct display of sorting indicators (▲ for ascending, ▼ for descending, ● for unsorted).
* Proper interaction with themodel.set andmodel.save_changes methods.

**How to Run**:To execute these tests from the project root directory:```bashcd tests/jsnpm install  # Only needed if dependencies haven't been installed or have changednpm test```

Thanks! Could you also add a workflow for this to our GitHub Actions folder?https://github.com/googleapis/python-bigquery-dataframes/tree/main/.github/workflows

Something like this:

name: js-testson: pushjobs:  build:    runs-on: ubuntu-latest    steps:    - uses: actions/checkout@v2    - name: Install modules      working-directory: ./tests/js      run: npm install    - name: Run tests      working-directory: ./tests/js      run: npm test

Yes, separate PR makes sense to me, thanks.

Could you move these styles to the CSS file?

Same with these.

Could usefooter to make the CSS easier.https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/footer

Same here. I think we can move these to the CSS file.

I don't think we want to allow 1000 rows in one page. That'd be a lot to scroll through if you select it by accident. Let's revert this to have[10, 25, 50, 100]

Thanks! Could you also add a workflow for this to our GitHub Actions folder?https://github.com/googleapis/python-bigquery-dataframes/tree/main/.github/workflows

Something like this:

name: js-testson: pushjobs:  build:    runs-on: ubuntu-latest    steps:    - uses: actions/checkout@v2    - name: Install modules      working-directory: ./tests/js      run: npm install    - name: Run tests      working-directory: ./tests/js      run: npm test

For the general case, column names could be any "Hashable" value, including integers

importbigframes.pandasasbpdimportpandasaspdbpd.options.bigquery.project="swast-scratch"df=bpd.DataFrame([[0,1], [2,3]],columns=pd.Index([1,2]))print(df)print(df[1])print(df[2])

Also, another very important case is the MultiIndex:

df=bpd.DataFrame({'foo': ['one','one','one','two','two','two'],'bar': ['A','B','C','A','B','C'],'baz': [1,2,3,4,5,6],'zoo': ['x','y','z','q','w','t']})pdf=df.pivot(index='foo',columns='bar',values=['baz','zoo'])print(pdf.columns)print(pdf[("baz","A")])

This isn't needed for SQL Cell, but we do need to make sure we function correctly in the general case. Could you test with these types of DataFrames?

If it's not feasible to support these in this PR, please avoid doing the sorting feature for those DataFrames for now and create a bug and a TODO to expand our support for any column label.

I disable these two cases for now and filed b/463754889

Could we file a bug and a TODO to support sorting by the index column(s) as well? For those, we'd use sort_index.

filed b/463715504