fix(webui): stop column header resize glitch, closes #1242

[mohamadyasser118]

Description

This PR fixes a UI glitch where the column header resize interaction caused layout instability in the WebUI.

Fixes #1242

Before:

Bug.mp4

After:

fix.mp4

AI & Automation Policy

• I am the human author and take full personal responsibility for every change in this PR.
• No AI or automated generative tool was used in any part of this PR OR I have disclosed all tool(s) below.

AI/automation tools used:

Drafted with the assistance of Claude Sonnet 4.6

Checklist

• Code compiles and existing tests pass locally.
• New or updated tests are included where applicable.
• Documentation is updated where applicable.

[Mazen050]

Hello, @mohamadyasser118

While testing the branch, I noticed two new problems:

1. The connection string column no longer resizes.

2. When shrinking other columns so that the total column width becomes smaller than the grid container, the connection string column automatically expands to fill the remaining space.

Because of this behavior, it becomes impossible to reach layouts like the one below, where unused space remains in the grid:

here the connection string column will expand to fill this gap

So the resizing behavior becomes inconsistent in these cases.

[mohamadyasser118]

Hello, @Mazen050
Thanks a lot for this feedback. You are absolutely right on both points. The root cause was in useGridState.ts
I made another commit to solve those issues. I think it's correct now, try it and tell me.
I will be grateful for any other notes.

Screen.Recording.2026-03-06.070021.mp4

[0xgouda]

It seems the resizing works fine, but now whenever I add/remove a column from the displayed list, the screen goes fully white:

result:

[mohamadyasser118]

@0xgouda

Check now

[pashagolub]

When I check new code I understand nothing. Would you please explain in your own words (without AI) what are the changes, why you implemented it this way, what was wrong with previous implementation?

[mohamadyasser118]

When I check new code I understand nothing. Would you please explain in your own words (without AI) what are the changes, why you implemented it this way, what was wrong with previous implementation?

Sure

let's begain with the part of (defaultSizing), this part can make a conflict with the columns that have flex rather than width, and this was the problem at Connection String column. When we lock back to SourcesGrid.consts file we can see that the columns have already default width so I thought that there is no need to another resizing, this will make us avoid any problems with Connection String column and any other with flex (if there will be).

this moves us to the part of (columnSizing) which was dependant on (defaultSizing), Now columnSizing should only contain widths the user set by dragging. If they haven't touched a column, it keeps its original definition (like at SourcesGrid.consts file)

the part of (saveToStorage) was deleted because all three handlers now call localStorage.setItem directly inside setGridState, so no need for a separate helper anymore.

let's move to the part of (handleColumnVisibilityChange) (which was the core problem of glitching)
the old version captured gridState at the time the function was created. If the state changed before this function ran, it would use outdated data, the new version uses the functional form of { setGridState(prev => ...) } which always receives the current state as prev, so it's always accurate.

the part of handleColumnResize also was updated to uses prev instead of capturing gridState.

resetColumnSizes should restore columns to their original definitions, whatever flex, width, or minWidth

useMemo now used to keep the array only recreated when columns or columnSizing actually changes, not on every render.

when we move to the file of SourcesGrid.tsx, I renamed the destructured handler and the prop

I just want to ensure that any AI assistance used to help understand and implement some of these changes I made sure to understand each change before applying it, and test it locally (as mentioned in AI Policy). That said, if you'd prefer to avoid any AI assistance going forward, I completely respect that and will do so.