refactor: Refactor various column details and add TypeMetadata to TableColumn model

[kristenarmes]

Signed-off-by: Kristen Armes [email protected]

Summary of Changes

These changes are made in anticipation of the upcoming work to add in nested columns retrieved from the backend rather than frontend parsing outlined here. This removes the dependence on the columns' indices around descriptions and side panel column details, and now relies on names and keys to be able to extend the same usage to nested columns.

• Add TypeMetadata in frontend model as an optional TableColumn field - this data was already being retrieved from the metadata API so now it is being populated
• Use the column name directly for getting/setting column descriptions rather than its index
• Add column key field to TableColumns to be used to keep track of which column is currently selected when the right side column details panel is open
• Remove the now unnecessary extra col_index field in TableColumn
• Also fixed the ListSortingDropdown to maintain the correct previous selection after the right side panel opens and closes

Tests

General cleanup of tests for changes outlined above, and added a test for the ListSortingDropdown to make sure it selects the new prop for the currently selected option

Documentation

N/A

CheckList

Make sure you have checked all steps below to ensure a timely review.

• PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"
  • In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.
• PR includes a summary of changes.
• PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
• In case of new functionality, my PR adds documentation that describes how to use it.
  • All the public functions and the classes in the PR contain docstrings that explain what it does

[allisonsuarez]

Do we have to rebuild the column key here? is it not indexed in neo4j?

[kristenarmes]

You're right that it is indexed, but it wasn't being returned from the metadata API. I thought about adding it to the neo4j proxy query but then realized that wouldn't guarantee that the key was available for those using other proxies, and this way would guarantee we'd always have the key in FE

[Golodhros]

LGTM