-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(base): Rewrite RoomNotableTags
#3111
Conversation
I believe this small refactoring makes the code simpler to read, esp. when more event type will be added.
This patch is the first step to remove the [`RoomNotableTags`] API. The idea is to compute the notable tags as a single 8-bit unsigned integer (`u8`) and to store it inside `RoomInfo`. The benefits are numerous: 1. The type is smaller that `RoomNotableTags`, 2. It's part of `RoomInfo` so: - We don't need an async API to fetch the tags from the store and to compute the notable tags, - It can be put in the store, - The observable/subscribe mechanism is supported by `RoomInfo` behind observable instead of introducing a new subscribe mechanism.
The previous patch has introduced the new `NotableTags` type to replace the `RoomNotableTags`. This patch removes the latter. This patch keeps the `Room::set_is_favorite` and `::set_is_low_priority` methods. However, this patch adds the `Room::is_favourite` and `::is_low_priority` methods, with the consequence of entirely hiding the notable tags type from the public API.
…vourite`. The Matrix specification uses the `m.favourite` orthography. Let's use the same in our code. So `set_is_favorite` becomes `set_is_favourite`. This patch updates this in various places for the sake of consistency.
Now that `NotableTags` has replaced `RoomNotableTags` entirely, this patch can rename `NotableTags` to `RoomNotableTags` as it's a better name for it. Note that this type is private to `matrix_sdk_base`, so it's fine to rename it.
The test is failing because the new way the notable tags are handled in The following extracts are from the So here, we handle the room account data: matrix-rust-sdk/crates/matrix-sdk-base/src/client.rs Lines 844 to 845 in 9bf48ef
A new
the “previous” A solution would be to run This API is really fragile. I'm OK to revisit it in this PR if that's required, or in another PR. |
This patch tests the `is_favourite` and `is_low_priority` methods.
The workflow inside `Client::receive_sync_response` is a little bit fragile. When `Client::handle_room_account_data` is called, it modifies `RoomInfo`. The problem is that a current `RoomInfo` is being computed before `handle_room_account_data` is called, and saved a couple lines after, resulting in overwriting the modification made by `handle_room_account_data`. This patch ensures that the new `RoomInfo` is saved before `handle_room_account_data` is called.
5352036
to
65774aa
Compare
This patch rewrites all the integration tests for the notable tags. The tests were good, but we could merge some together. The names were too long, they have been shortened.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3111 +/- ##
==========================================
+ Coverage 83.72% 83.76% +0.03%
==========================================
Files 229 229
Lines 23654 23646 -8
==========================================
+ Hits 19805 19807 +2
+ Misses 3849 3839 -10 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks!
// Save the new `RoomInfo`. | ||
changes.add_room(room_info); | ||
|
||
self.handle_room_account_data(&room_id, &new_info.account_data.events, &mut changes) | ||
.await; | ||
|
||
// `Self::handle_room_account_data` might have updated the `RoomInfo`. Let's | ||
// fetch it again. | ||
// | ||
// SAFETY: `unwrap` is safe because the `RoomInfo` has been inserted 2 lines | ||
// above. | ||
let mut room_info = changes.room_infos.get(&room_id).unwrap().clone(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the way it's done in the sliding-sync variant of this function, is that we edit the room_info
, and don't mess at all with the changes
until the end of the function where we put the room info into the changes. We should do that here too, for consistency at least. I'll write a followup.
pub fn handle_notable_tags(&mut self, tags: &Tags) { | ||
let mut notable_tags = RoomNotableTags::empty(); | ||
|
||
if tags.contains_key(&TagName::Favorite) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haha, now Ruma needs an update for TagName::Favourite
too ^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed!
Signed-off-by: Benjamin Bouvier <public@benj.me>
Signed-off-by: Ivan Enderlin <ivan@mnt.io>
Rebase failed
@bnjbvr If I understand correctly, the migration is not handled properly, the existing tags (saved in the account data store) won't be inserted in room info, right? |
@ganfra Good question; if the tags aren't sent as part of an initial sync response all the time, then yes they might be missing. Otherwise if they're in the initial sync response, we should handle them properly. Are you observing some issues about that? |
I've not yet used the new PR, will report any issue with that. |
This PR must be reviewed commit-by-commit.
This PR entirely revisits the
RoomNotableTags
API (introduced in #3071 and #3075). The idea is to compute the notable tags as a single 8-bits unsigned integer (u8
) and to store it insideRoomInfo
. The benefits are numerous:RoomNotableTags
,RoomInfo
so:RoomInfo
behind observable instead of introducing a new subscribe mechanism.The PR ends up providing
Room::is_favourite
andRoom::is_low_priority
as simple non-async getters, which is needed by #3021.