UIProviders/Widgets have too much power

[ben-polinsky]

Hi,

Recently we encountered a situation where a widget was making fairly expensive calls to a backend and slowing down viewer initialization. While there were other issues with startup making the app slow, it got me thinking - why are widgets granted the power to bring apps to a crawl if they aren't even visible? Why is it left up to the widget creator to handle the conditions of initialization (by checking the widget state and listening to widget state change events)?

Couldn't we provide UiProviders initialization and events through props? There could be an eager init callback for any loading the widget might have to do before it is activated. This would make it much more clear how UIProviders are supposed to be initialized and ensure they don't slow down viewer startup.

Either way, I think UI docs should mention something about this.

[GerardasB]

Good callout about the docs, I'll update the documentation of different WidgetState(s).

To solve the described problem you are probably looking for the WidgetState.Unloaded, which allows you to register a widget without rendering/mounting the specified content node (keep in mind, that changing the widget state to Unloaded will unmount the content node if it was previously rendered - https://react.dev/learn/lifecycle-of-reactive-effects).

This is different from WidgetState.Hidden, which will render the content node, but will not display/expose it through the UI (i.e. related widget tab is not displayed, widget content is not visible either). This is useful in multiple scenarios, like bootstrapping/pre-initialization OR maintaining the state of a widget, while temporary hiding it in the UI.

[ben-polinsky]

Thank ya.