Deprecation of ComponentVisibility / shouldShowComponent from Customisations not handled by Module-API

[JohnSimonsen]

Your use case

What would you like to do?

As customisations has been deprecated, there is no substitution in place to handle custom condition checks in regards to visibility of components. By the looks of it - the functionality hasn't been removed from the codebase yet, but will be in a future release.
(See cusomisations.md )

My proposal is to await with the complete deprecation/removal of the ComponentVisibility / shouldShowComponent from the codebase. And perhaps suggest that the feature should be reworked, or live on under a new guise when the time for removal of customisations has come.

Why would you like to do it?

We customise our app and use the shouldShowComponent functionality in order to customise what our users see.
Most recently we've used it to manage which users have access to UIComponent.createSpaces.

We wish to continue use it - as we think this feature will continue to be relevant in our current and future work to bring our fork of element as close as possible to the upstream. Ideally we should be able to fully support our customisation needs by extension/customisation/modules in Element. In order to achieve this, we are currently increasing our resources spent on achieving this goal, this should mean increased contributions and PR's attempting to solve our and others' customisation challenges, and we think shouldShowComponent could play an essential part.

How would you like to achieve it?

Await complete removal of custom component visibility.

Have you considered any alternatives?

Other alternatives would either:

• Require a re-implematation to replace functionality already supported.
• Implement a new solution to the same feature using other means.
• Lose useful functionality

As Customisations is deprecated and Module-Api inherits the main responsibility for future custom functionality, it might sound logical that there should be an module extenstion for this as well. The Module-API however, might have challenges resolving dependencies to matrix-react-sdk.

Additional context

An important part of this suggestion is to document that 'someone' is using this functionality which will be removed.

Our team will undertake a large refactor of our fork in the coming weeks to try to make our customisations as non-intrusive as possible. During this process, we will discover definitely, if this feature is as important to us as we think.

[JohnSimonsen]

Moving this issue to matrix-react-sdk-module-api instead, probably a more sensible place to solve this issue.

Edit: matrix-org/matrix-react-sdk-module-api#32