controlWidgetVisibility: Give us your thoughts!

[GerardasB]

Feature description

The controlWidgetVisibility feature enhances widget containers by introducing additional buttons in their title bar. These buttons provide the functionality to add or remove widgets, giving users more control over the visibility and organization of their widgets. This feature aims to improve user interaction and customization capabilities within the application.

The preview feature uses existing APIs, so widgets with the WidgetState.Hidden or WidgetState.Unloaded state will show up in the dropdown menu when Add widget is clicked. When the Close widget button is clicked state is set to WidgetState.Hidden. That means that the widget React and DOM state is persisted as well.

For use cases where application logic would prefer to keep widgets "hidden" until some condition, we suggest registering/unregistering a provider only when needed.

Live demo

Note

Released in 4.14.0.

Why is it a preview feature?

• The widget title bar area is getting crowded, so widgetActionDropdown or another strategy might be required
• We want to determine if the new behavior should be the default and only option, or rather if it should be an "opt-in" and require related APIs to be configurable.
• Currently, applications can show and hide the widgets programmatically. Exposing an entry point to unhide widgets might conflict with the application's logic.

[a-gagnon]

I'd vote to make this an opt-in feature. I see the benefits for some widgets that are expected to be presented at all times (ex. properties, model/category selector), but less so for civil profile, sheet viewer, or any other 'state sensitive' widget.

[GerardasB]

I'd vote to make this an opt-in feature. I see the benefits for some widgets that are expected to be presented at all times (ex. properties, model/category selector), but less so for civil profile, sheet viewer, or any other 'state sensitive' widget.

Currently, you can provide an array of widgets that can be added/closed by the user.
However, I'd prefer to find another solution, because it is not transparent to the user why certain widgets can be hidden while others - can not.
One of the suggestions is to register a provider with such widgets as needed, but more testing needs to be done if that satisfies all use cases.

[wilmaier]

I was initially confused when I saw add/close widget but discovered that it means show/hide widget. So why not just use those words since they seem more clear as to what is happening?

[simihartstein]

I agree it should be an opt-in feature, but I'd personally rather have an option on the tab itself, similar to how it would work in a browser.
From a tech perspective, I'd want this as an option on the WidgetConfig, with an exposed event, so I may control tear-down (rather than being limited to a hidden state)
In my use-case it would make sense that the application would be responsible for reopening the widget. I see the ux concern of some tabs having the option while others don't. I don't have a general solution for this, but I would be ok with it falling under the responsibility of the application to address it.

[simihartstein]

@GerardasB Has there been any movement on this? My team would love to adopt it, but I want to get an idea if/when this would come out of preview.

[GerardasB]

Thanks for the feedback. You can start using it as is (via preview features) and provide additional comments/requests if there are any. From AppUI side we can look into exposing this long term, but I have no ETA currently.

[simihartstein]

The reason I ask is because we have a directive not to use beta features for stability reasons. I'll see if we can make an exception for this.

[GerardasB]

I see, I think we should bump the PreviewFeatures APIs to public either way

[GerardasB]

Bumped release tags: #1517