feat(cdk/table): cache cells when updating columns

[LuisWolf-Snapaddy]

Feature Description

When adding / removing rows to / from a DataSource the component tree is updated efficiently and only the rows that changed get rebuild (can be easily tested by logging something inside the ngOnDestroy lifecycle in a cell component).

However, updating the array of visible columns, destroys all rows and recreates all rows incl. all cells (see

components/src/cdk/table/table.ts

Lines 1067 to 1098 in 974d42f

	/**
	* Check if the header, data, or footer rows have changed what columns they want to display or
	* whether the sticky states have changed for the header or footer. If there is a diff, then
	* re-render that section.
	*/
	private _renderUpdatedColumns(): boolean {
	const columnsDiffReducer = (acc: boolean, def: BaseRowDef) => {
	// The differ should be run for every column, even if `acc` is already
	// true (see #29922)
	const diff = !!def.getColumnsDiff();
	return acc || diff;
	};
	// Force re-render data rows if the list of column definitions have changed.
	const dataColumnsChanged = this._rowDefs.reduce(columnsDiffReducer, false);
	if (dataColumnsChanged) {
	this._forceRenderDataRows();
	}
	// Force re-render header/footer rows if the list of column definitions have changed.
	const headerColumnsChanged = this._headerRowDefs.reduce(columnsDiffReducer, false);
	if (headerColumnsChanged) {
	this._forceRenderHeaderRows();
	}
	const footerColumnsChanged = this._footerRowDefs.reduce(columnsDiffReducer, false);
	if (footerColumnsChanged) {
	this._forceRenderFooterRows();
	}
	return dataColumnsChanged || headerColumnsChanged || footerColumnsChanged;
	}

).

It would be super helpful for bigger tables where cells include components that are destroyed and re-created on column changes to cache and re-use existing cells. Meaning instead of clearing the view of each row, creating a diff of columns inside each row to only touch columns that actually changed (add new ones, remove old ones, move cells where the column was re-ordered).

Use Case

This would allow for more performance when working with bigger tables, without the need for some kind of virtual scrolling.