Section in running sidebar triggers React rerender on any tab switch even if hidden

[krassowski]

Description

On initialization of running sidebar Section (PanelWithToolbar subclass) a ReactWidget observing options.manager.runningChanged signal is created:

jupyterlab/packages/running/src/index.tsx

Lines 248 to 266 in 552cdfe

	this.addWidget(
	ReactWidget.create(
	<UseSignal signal={options.manager.runningChanged}>
	{() => {
	return (
	<div className={CONTAINER_CLASS}>
	<List
	runningItems={options.manager.running()}
	shutdownLabel={options.manager.shutdownLabel}
	shutdownAllLabel={shutdownAllLabel}
	shutdownItemIcon={options.manager.shutdownItemIcon}
	translator={options.translator}
	/>
	</div>
	);
	}}
	</UseSignal>
	)
	);

There are two problems

• this signal fires too often leading to unncessary re-rendering when tab was switched (rather than closed/removed), which is because no filtering of the tabsChanged signal takes place - it is just proxied as-is:
  

  jupyterlab/packages/running-extension/src/opentabs.ts

  Line 85 in 552cdfe

  runningChanged: signaler.tabsChanged,

• this signal is received and triggers re-render even if the running sidebar is closed; it should be proxied in the widget and skipped if widget isHidden.

Reproduce

1. Record profile
2. Change tab
3. See that running sidebar was re-rendered

Expected behavior

Hidden widgets do not re-render unnecessarily.

We could use props.shouldUpdate for UseSignal.

Context

• JupyterLab version: 4.0.0.a31

[krassowski]

this signal fires too often leading to unnecessary re-rendering when tab was switched (rather than closed/removed), which is because no filtering of the tabsChanged signal takes place - it is just proxied as-is:

This one is difficult because the original signal comes from lumino's title.changed which emits without any data from changes to text, icon or className; it is reasonable that we listen to this signal because we may want to sync some of the title styling changes (e.g. text, icon, maybe colour in the future) in the "Open tabs" section of the running panel. The problem is that this changed fires on tab switch as a consequence of className update and we would need to make assumptions on what class name changes mean "tab switched" (and therefore are safe to ignore) and which should possibly need to be propagated.

I can also imagine a feature request of highlighting active tab in the panel so maybe this is not a priority.