Notebooks code cleanup

[roblourens]

• Review internal APIs
  • NotebookEditorWidget
  • NotebookViewModel
  • NotebookTextModel#applyEdits
• More work on notebookExecutionService.ts (Notebook cell execution isn't managed in the renderer #125668)
• Clean up cellRenderer.ts
• CSS cleanup Clean up notebook CSS #140133

[rebornix]

My wish list of internal API of the notebook editor component:

• No .viewModel usage in contrib
  • This means we would need API on NotebookEditorWidget
• Unify mulit-selection aware notebook actions

[roblourens]

I think probably everything except my cellRenderer task is done? Anything else you plan to do?

[rebornix]

Yeah, the only thing left is polishing cell renderer. Let's finish that next month.

[rebornix]

Potential issues found while refactoring the cell renderer:

• CSS for dnd doesn't work for markdown cell as it's webview based

  vscode/src/vs/workbench/contrib/notebook/browser/view/renderers/cellRenderer.ts

  Lines 162 to 166 in 57f6be8

  	if (element.dragging) {
  	templateData.container.classList.add(DRAGGING_CLASS);
  	} else {
  	templateData.container.classList.remove(DRAGGING_CLASS);
  	}

  . Suggestion for fixing this would be moving dnd completely out of the cellRenderer and use decoration API which can work in both main and iframe @roblourens

[rebornix]

As part of the refactoring, we introduced the concept of CellPart which is an abstraction of components in a cell component, e.g., Toolbar, ProgressBar, Output. A CellPart should try its best to construct DOM and update DOM nodes in its ctor or updateLayout, and perform DOM read operations only in prepareLayout to ensure that DOM write and read operations are batched along with other cell parts. A cell part doesn't need to bind its own listener to cell state change, the events will be passed in through CellPart#updateState.