Skip to content
This repository was archived by the owner on Jan 30, 2025. It is now read-only.

Add support to customize UI components rendering#12

Closed
maheichyk wants to merge 11 commits into
matrix-org:mainfrom
nordeck:ui_component_lifecycle
Closed

Add support to customize UI components rendering#12
maheichyk wants to merge 11 commits into
matrix-org:mainfrom
nordeck:ui_component_lifecycle

Conversation

@maheichyk
Copy link
Copy Markdown
Contributor

@maheichyk maheichyk commented Mar 15, 2023

This PR suggest to extend module API with possibility to control rendering of UI Components.

Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
Comment thread src/lifecycles/UiComponentLifecycle.ts Outdated
@maheichyk maheichyk marked this pull request as ready for review March 15, 2023 08:45
@maheichyk maheichyk requested a review from a team as a code owner March 15, 2023 08:46
@maheichyk maheichyk requested review from SimonBrandner and dbkr March 15, 2023 08:46
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
@maheichyk
Copy link
Copy Markdown
Contributor Author

This PR relates to this draft in matrix-react-sdk: matrix-org/matrix-react-sdk#10382 Could you please review?

Copy link
Copy Markdown

@SimonBrandner SimonBrandner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks sane

Comment thread src/lifecycles/UiComponentLifecycle.ts Outdated
Comment thread README.md
maheichyk and others added 5 commits June 15, 2023 17:43
Co-authored-by: Šimon Brandner <simon.bra.ag@gmail.com>
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
@maheichyk maheichyk requested a review from SimonBrandner June 15, 2023 15:01
Copy link
Copy Markdown
Contributor

@germain-gg germain-gg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the code looks fair, but I'm lacking a bit of context here

  • It appears that those UI customisations are already possible today. Why advantages do you see with the approach you're suggesting?
  • How can we ensure that files stay in sync across codebases?

Comment thread src/lifecycles/UIComponentLifecycle.ts
Comment thread src/lifecycles/UIComponentLifecycle.ts
Comment on lines +49 to +66
/**
* Components that lead to a user being invited.
*/
InviteUsers = "UIComponent.sendInvites",

/**
* Components that lead to a room being created that aren't already
* guarded by some other condition (ie: "only if you can edit this
* space" is *not* guarded by this component, but "start DM" is).
*/
CreateRooms = "UIComponent.roomCreation",

/**
* Components that lead to a Space being created that aren't already
* guarded by some other condition (ie: "only if you can add subspaces"
* is *not* guarded by this component, but "create new space" is).
*/
CreateSpaces = "UIComponent.spaceCreation",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe a more appropriate avenue for this kind of feature would be to piggy back off user permissions on a server as described in matrix-org/synapse#7731

I appreciate this issue has not received a lot of attention in recent times, but it seems like a more forward looking way to handle this

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably could be used if implemented already, but it seems just and idea at the moment. But we would like some users (guests with special user ids) not to be able to invite, create rooms or spaces. Would be good to use a module API for that.

Copy link
Copy Markdown
Contributor

@germain-gg germain-gg Jul 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is already possible using a feature flag UIFeature.widgets as defined in UIFeature.ts. See settings.md in the matrix-react-sdk for usage

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UIFeature.widgets seems to toggle rendering of the integration manager. How should this be connected with InviteUsers, CreateRooms, CreateSpaces functionality to be hidden or shown based on user ids? Could you please clarify?

matrixUserId: string
) => void;

export enum UIComponent {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seem to be a copy/paste of UIFeature.ts in the matrix-react-sdk.
Before considering this i'd want to explore ways to keep the two in sync. I'm actually unsure what value this brings over the existing possible customisations?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is true, I have mentioned this in my first comment. Maybe a solution could be to change react-sdk to use a UIComponent from this PR? Or any other idea?

Based on this matrix-org/matrix-react-sdk#9931 (comment) we may think that component visibility customization API is deprecated in favor of module API.

This solution would simplify our deployment, maybe quite a lot. We plan to put all visibility customizations and landing for guests in a separate module.

@maheichyk maheichyk requested a review from germain-gg July 6, 2023 14:05
Copy link
Copy Markdown
Contributor

@germain-gg germain-gg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for replying to the comments in line. I don't think you've adressed the two questions asked in the original review i gave to this PR.
I'd be interested to hear more about this, before that moves forward

@maheichyk
Copy link
Copy Markdown
Contributor Author

@germain-gg please find my answers/comments:

* It appears that those UI customisations are already possible today. Why advantages do you see with the approach you're suggesting?

Based on this matrix-org/matrix-react-sdk#9931 (comment) we may think that component visibility customization API is deprecated in favor of module API.

In this PR matrixUserId is passed into the module and can be used to decide if component should be shown or not. We disable some functionality for the guest users with specific ids. It seems to be bot possible within existing APIs.

This solution could simplify our deployment. We plan to put all visibility customizations logic and landing for guests into a separate module.

* How can we ensure that files stay in sync across codebases?

A solution could be to change matrix-react-sdk to use a UIComponent from this PR.

@maheichyk maheichyk requested a review from germain-gg July 10, 2023 06:19
@germain-gg germain-gg requested review from germain-gg and removed request for germain-gg July 13, 2023 07:59
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
@maheichyk
Copy link
Copy Markdown
Contributor Author

@germain-gg I changed this PR a bit, could you please have a look? Maybe PR can be moved forward.

@Johennes
Copy link
Copy Markdown
Contributor

Johennes commented Sep 5, 2023

@dhenneke / @maheichyk just checking, is this still something you're hoping to get landed?

# Conflicts:
#	README.md
#	src/lifecycles/types.ts
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
@maheichyk
Copy link
Copy Markdown
Contributor Author

@Johennes yes would be great to have it, thanks for you message! I have updated the branch to latest main changes.

@Johennes
Copy link
Copy Markdown
Contributor

Johennes commented Sep 6, 2023

@maheichyk many apologies for the delay you had to endure here so far. We discussed this internally today with @t3chguy, @andybalaam and @clokep. The approach of implementing this via the module API as you did is not unreasonable. However, we think there is an alternative to this that leverages Synapse and, with limited complexity, would allow exposing this feature on all clients while offering a single point of configuration.

The CS-API already includes the authenticated /capabilities endpoint that lists things the server allows your user to do such as m.change_password. The specific UIComponents you mentioned above (InviteUsers, CreateRooms, CreateSpaces) would fit in well there.

What would be needed to implement this is the following:

  • An MSC that describes new server-side capabilities for InviteUsers, CreateRooms and CreateSpaces as well as new error codes for the end points affected by them
  • A change to EW to en-/disable the respective UI elements based on the /capabilities response
  • A change to Synapse to make the APIs affected by the new capabilities (such as /createRoom) value them
  • A change to Synapse's capabilities servlet that allows injecting capabilities (based on the user's ID) using a Synapse plugin

We can help drafting the MSC and review pull requests but would need you to direct your development efforts to the other three points.

Can you please let us know if this option seems viable to you?

@maheichyk
Copy link
Copy Markdown
Contributor Author

@Johennes thanks for the details, we will discuss this internally and inform you within next few days.

@maheichyk
Copy link
Copy Markdown
Contributor Author

@Johennes we are using existing deprecated API to customize rendering of components and are not blocked by this PR. In general the idea is good, but we don't plan to work on this topic at the moment.

@Johennes
Copy link
Copy Markdown
Contributor

Thanks for getting back @maheichyk. Makes sense. I'll close this for now then.

@Johennes Johennes closed this Sep 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants