Show non-member room state across list and room view

[tyreseluo]

PR Content

• keep left/banned rooms visible with status hint
• switch input bar to membership footer and stop typing actions
• update restore status view for persisted rooms

1. if any administer ban somebody, the room screen will show:

and you can't re-join again, but if administer unban, it will show: and you can re-join again.

2. if you has been removed, if this room join rule is can re-join again, seem about administer unban you solution above.

3. if adminster changes room's join rule, seem room_input_bar will display differece view.

• public (user can easy to re-join)
• invite olny (adminster must re-send a invitation)

like this flow: user joined -> adminster remove user -> adminster send invitation again -> user can accpet or reject.
-> if user accept, the normal join room process.
-> if not(below):

If the user has previously visited this room, the room will remain accessible, but the user will be unable to send messages and can only view historical messages. If the user has never visited this room, they will enter the standard rejection process.

PR Related PR/Issue

• Show a clear message/view when the user is no longer a joined member of a room (after leaving or getting kicked/banned) #656

[tyreseluo]

@kevinaboos Although this PR is ready for review, but i think we need to wait #640 RoomLoadingScreen widget, because this PR still use RestoreStatusView widget, so anytime if #640 was merged and we can use RoomLoadingScreen, i will modify this PR, move RestoreStatusView to RoomLoadingScreen widget.

[kevinaboos]

@kevinaboos Although this PR is ready for review, but i think we need to wait #640 RoomLoadingScreen widget, because this PR still use RestoreStatusView widget, so anytime if #640 was merged and we can use RoomLoadingScreen, i will modify this PR, move RestoreStatusView to RoomLoadingScreen widget.

Yes, I agree. I left a detailed comment on #640. Once you read that, I think you'll agree that a single LoadingScreen widget could also be used for the purposes of this PR, i.e., to display a room that the user was previously a joined member of, but has since left or been kicked/banned.

I skimmed the code here on this PR and am not sure that I'm on board with your approach. You're making things way too complex by trying to re-use existing infrastructure for something that really ought to be handed separately. For example, you're using the joined rooms set in the RoomsList to store rooms that the user is no longer a member of, which is not only confusing but also violates the invariant of that type. It also won't work with the room list service, because that service needs to be able to remove rooms that the user has left. It'd be much clearer and better in the long run to just explicitly add support for left/kicked/banned rooms (and Knocked rooms, since that's the only other type) and to have the RoomsList track those separately.

I think it's best if we put this PR on hold until the LoadingScreen design is completed.

[tyreseluo]

Thanks for your review.

I think it's best if we put this PR on hold until the LoadingScreen design is completed.

i agree.

It also won't work with the room list service, because that service needs to be able to remove rooms that the user has left. It'd be much clearer and better in the long run to just explicitly add support for left/kicked/banned rooms (and Knocked rooms, since that's the only other type) and to have the RoomsList track those separately.

yep, i agree. I'll give it some more careful thought.

As you mentioned, the current design is still too complex and quite messy.

i will waitting for #640