fix: Use Map for O(1) column lookups in table width calculations

[TrevorBurnham]

Description

Currently the table width calculations use repeated find calls across columns in getColumnStyles, which is called for each column, so worst-case performance is O(n^2). This PR switches to creating a Map for that lookup, making performance consistently O(n).

How has this been tested?

This functionality is well-covered by existing tests.

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

• Changes include appropriate documentation updates.
• Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
• Changes do not include unsupported browser features, see CONTRIBUTING.md.
• Changes were manually tested for accessibility, see accessibility guidelines.

Security

• If the code handles URLs: all URLs are validated through the checkSafeUrl function.

Testing

• Changes are covered with new/existing unit tests?
• Changes are covered with new/existing integration tests?

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.14%. Comparing base (1a5715e) to head (2f3337c).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4142   +/-   ##
=======================================
  Coverage   97.14%   97.14%           
=======================================
  Files         873      873           
  Lines       25642    25643    +1     
  Branches     9284     9284           
=======================================
+ Hits        24910    24911    +1     
  Misses        726      726           
  Partials        6        6           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pan-kot]

The visibleColumns is created on every render, so there is no reason to memoize this computation - it will still recompute every time.

[pan-kot]

btw, it is not O(1) as specified in the PR description but O(n) - which is the cost of dictionary creation

[TrevorBurnham]

Good catch! I've updated this PR to memoize visibleColumns as well.

[pan-kot]

But why all this memoization is needed? It adds a lot of clumsiness to the code but the performance impact of transforming columns is negligible even if there are 100 columns, which is rare.

[TrevorBurnham]

So, the memoization is actually a much bigger win than the Map change: Every time this useEffect gets triggered, it calls updateColumnWidths, which is potentially very expensive because it makes DOM measurements with getBoundingClientRect(). Doing that on table renders that don't affect the column widths is a recipe for making interactions feel slow. I'm sure you've experienced times where there's noticeable lag when typing in a Cloudscape table's search box; the updateColumnWidths call is likely a big contributor to that lag.

[TrevorBurnham]

I've updated this PR with a "does not measure column widths when re-rendering with unchanged columns" test, which I think is useful for validating the performance improvement here and preventing future regressions.