Column Pinning

pin: 'left' and pin: 'right' are the whole API. Four columns declare one here, and the eight between them scroll:

{ key: 'id',        name: '#',       width:  64, pin: 'left'  },
{ key: 'firstName', name: 'Name',    width: 150, pin: 'left'  },
…
{ key: 'status',    name: 'Status',  width: 110, pin: 'right' },
{ key: 'actions',   name: 'Actions', width: 100, pin: 'right' },

They stack in array order, running inward from the edge: # sits at the very left because it comes first, with Name beside it; on the other side Actions sits at the very right because it comes last. Reorder the array and the frozen pair reorders with it.

Only the column that touches the scrolling area carries the seam. On the left that is Name, not # — the boundary between the two of them is an ordinary column separator, because it is not where frozen meets scrolling. The seam marks that one edge and nothing else, and scrolling sideways leaves it exactly as strong at every position, including the very end of the travel.

The selection checkbox is not one of your columns and it is frozen too. It is prepended before every pinned-left column and its sticky offset is worked out for you, so combining rowSelection or rowExpand with pinning needs no offset arithmetic on your side.

Nothing on this grid's columns array declares a pin except #. The first three buttons move Email by writing a state snapshot back:

setPin(key: string, pin: ColumnPin | undefined) {
  const columns = (grid.getState().columns ?? [])
    .map(c => (c.key === key ? { ...c, pin } : c));

  grid.setState({ columns });
}

Watch the two readouts under the grid: Frozen now and Column order are both read back out of getState() after each press, so what you see is the grid's own account of itself rather than this page's.

Hand back the whole list, always

A column snapshot restores the order from each entry's position in the array — not from its order field, which is recorded for you but not read back. The fourth button is the proof, and it is telling the truth when it does it:

grid.setState({ columns: [{ key: 'email', order: 6, pin: 'left' }] });

Email really is the seventh column, so order: 6 is correct. Press the button and Email still arrives at the front of the order, ahead of #, because it is the only entry in the array and the nine columns the snapshot never mentions have no position left to keep. Read the Column order line; Reset layout puts it back.

Reading the current state and mapping over it is what keeps the other nine columns where they are. It is also why this beats rebuilding your columns array: resize a column, then pin Email, and the width survives — a width the reader dragged lives in the grid's state, not in the array your component holds, so handing the grid a freshly built array would put it back to its declared value.

ColumnPin is 'left' | 'right', and undefined is the third value — a snapshot entry carrying pin: undefined clears an existing pin, which is what Unpin sends.