Do not wait for "displayed" before applying the layout

[martinRenou]

See #2762

Also fix #2605

And trigger a "layout-applied" event

[github-actions]

👈 Launch a binder notebook on branch martinRenou/ipywidgets/apply_layout_before_displayed

[martinRenou]

Adding a "layout-applied" event to the widget, we need to document this

[martinRenou]

We might need to revert this

[vidartf]

If we are reverting the other one, we should also revert this one.

[vidartf]

From reading the code in the core ipywidgets repo, I made these notes:

1. The layoutPromise and stylePromise are currently typed as Promise<any>, but at least the stylePromise is used under the assumption that it is a Promise<undefined | StyleView>:

   ipywidgets/packages/controls/src/widget_selection.ts

   Lines 561 to 565 in c7bd329

   	this.stylePromise.then(function (style) {
   	if (style) {
   	style.style();
   	}
   	});

2. By not waiting for the displayed promise before calling setLayout, there is an opportunity for the StyleView to be initialized before the render method of the owning widget is called. If this happens, the child elements of the widget might not be created yet, which means that any styles applied via query strings will fail to be applied (e.g. DescriptionWidget, IntSlider, etc.). This will not currently happen for the example widgets, since they create their child elements before any await calls in the render method, but there is no guarantee that this is true for all third-party widgets.

So in conclusion: If we decide to go ahead with this pattern, point 1. needs to be addressed. On the other hand, I think we should ensure that setStyle (and probably also setLayout for consistency) does not get called until the initial render method of the view has resolved. The displayed promise seems to be the best bet for this, so I would much prefer a solution that keeps this pattern.

[vidartf]

To expand on the race condition mentioned above:

class MyWidgetView extends DOMWidgetView {
  async render() {
    await someAsyncAction();
    // Create DOM elements here
  }
}

AFAICT, the DOM element creation is likely to happen after the styles are applied. Ref:

ipywidgets/packages/base/src/widget_style.ts

Line 52 in 441135a

this.style();

ipywidgets/packages/base/src/widget_style.ts

Lines 83 to 85 in 441135a

	const elements = selector
	? parent.el.querySelectorAll<HTMLElement>(selector)
	: [parent.el];

Example of a style that has a selector for a child element:

ipywidgets/packages/controls/src/widget_int.ts

Lines 37 to 50 in 441135a

	export class SliderStyleModel extends DescriptionStyleModel {
	defaults(): Backbone.ObjectHash {
	return { ...super.defaults(), _model_name: 'SliderStyleModel' };
	}
	public static styleProperties = {
	...DescriptionStyleModel.styleProperties,
	handle_color: {
	selector: '.noUi-handle',
	attribute: 'background-color',
	default: null as any,
	},
	};
	}

I haven't been able to find any examples of a real-life widget that has both an async render method AND a style selector that targets a child element, but that doesn't mean it doesn't exist, and I believe we should support it if it does (as we currently do).

[martinRenou]

Right. Let's close this PR then, and not touch this logic as it might break.

I will open a separate PR that only adds a "layout-applied" and a "style-applied" event, this should be enough.