allow re-ordering columns within table widget

[radheshpai87]

Fixes #4753

Technical details
Based on previous closed PR #4980

Previously, when columns were reordered in the main table view, the
table widget on the record page would not reflect the new column order.

This fix adds explicit reactivity tracking for table.metadata.column_order
within the TableWidget component. When the column order changes, the
TabularData instance is recreated with the updated table metadata,
ensuring the widget displays columns in the correct order.

The solution maintains component encapsulation by handling all reactivity
logic internally within TableWidget, without requiring changes to the
parent Widgets component.

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the develop branch of the repository
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I tried running the project locally and verified that there are no
  visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[radheshpai87]

@seancolsen I have tried a different approach which ensures component encapsulation.

[radheshpai87]

Hey @seancolsen, just checking in — are my changes okay, or should I make any additional updates?

[seancolsen]

@radheshpai87

Sorry, but I'm having trouble deciding how to proceed here.

This does seem to work. But the code has some strange patterns that I'm hesitant to merge. I'd rather not take the time to explain why right now.

I did some work myself towards implementing this fix "the right way", but I ran into a bug in a different part of the codebase that is proving tricky to track down. Overall, I need to make sure I don't spend too much time on this since it's not a high priority for maintainers right now.

I'd like to keep the open and potentially come back to it later.

For what it's worth, the direction I wanted to head was to use this code in Widgets.svelte:

function buildWidgetInput(
  joinableTable: JoinableTable,
  tablesData: TablesData,
) {
  const table = tablesData.tablesMap.get(joinableTable.target);
  if (!table) return undefined;
  const fkColumnId = joinableTable.join_path[0].slice(-1)[0][1];
  const { name } =
    joinableTablesResult.target_table_info[table.oid].columns[fkColumnId];
  return { table, fkColumn: { id: fkColumnId, name, metadata: null } };
}

$: tableWidgetInputs = joinableTablesResult.joinable_tables
  .filter((joinableTable) => joinableTable.multiple_results)
  .map((joinableTable) => buildWidgetInput(joinableTable, $currentTablesData))
  .filter(isDefinedNonNullable)
  .sort((a, b) => a.table.name.localeCompare(b.table.name));

Along with sorting out the import for TablesData, this is a very small change that I was expecting to fully address the problem. But it's surfacing what seems to be a different bug. I'm not sure why. I'm not even 100% positive this is the best direction to head. Just leaving this comment here so that I can move on. If you choose to follow this lead, please keep in mind that I need to minimize my time spent on this issue, so please resist the urge to ask follow-up questions. If you'd like to push something else that you think will work, then I can take a quick look.