Calculated TableView columns widths are sometimes inaccurate due to state `setTableWidth`

[LFDanLu]

🐛 Bug Report

We've seen a case where an initially hidden column renders with a width of 0 instead of its provided minWidth. It seems to due to setTableWith here becoming stale, which causes column widths to be calculated against an outdated columns prop.

🤔 Expected Behavior

Newly added column is rendered with the proper width

😯 Current Behavior

Newly added column is rendered with 0px width

💁 Possible Solution

Add setTableWidth to dep array here

🔦 Context

💻 Code Sample

Sandbox example: https://codesandbox.io/s/brave-pare-ntibeu?file=/src/App.js. This example doesn't actually exhibit the broken behavior but models the setup the user was seeing.

🌍 Your Environment

Software	Version(s)
react-spectrum	3.21.2
Browser
Operating System

🧢 Your Company/Team

[LFDanLu]

Rough code flow:

1. setTableWidth is computed every render. It makes use of columns obtained from state(i.e. state.collection from useTableState) which isn't a problem so long as you use the updated setTableWidth when calling it from other hooks/code. (Side note: probably should make this a useCallback)
2. TableView uses setTableWidth in

   react-spectrum/packages/@react-spectrum/table/src/TableView.tsx

   Lines 400 to 411 in e514827

   	let onVisibleRectChange = useCallback((rect: Rect) => {
   	setTableWidth(rect.width);
   	state.setVisibleRect(rect);
   	if (!isLoading && onLoadMore) {
   	let scrollOffset = state.virtualizer.contentSize.height - rect.height * 2;
   	if (rect.y > scrollOffset) {
   	onLoadMore();
   	}
   	}
   	}, [onLoadMore, isLoading, state.setVisibleRect, state.virtualizer]);

   . Since this makes use of useCallback, it doesn't recompute onVisibleRectChange when setTableWidth changes, meaning we may not be computing with the latest columns received via props

[snowystinger]

setTableWidth is a new function every render, it should probably be memo'd as well, or onVisibleRectChange will also update every render.

[snowystinger]

this should be fixed now by #3672, @LFDanLu do you have a test case you could check against it?

[LFDanLu]

Nah, didn't have a reproduction of the above error but I'll ping the team that did to try it out

[snowystinger]

Closing, inactivity and should be fixed