matrix-rust-sdk/crates/matrix-sdk/src/sliding_sync/list/builder.rs

178 lines
5.9 KiB
Rust
Raw Normal View History

//! Builder for [`SlidingSyncList`].
use std::{
fmt::Debug,
sync::{atomic::AtomicBool, Arc, RwLock as StdRwLock},
};
2023-03-10 11:09:08 +00:00
use eyeball::unique::Observable;
use eyeball_im::ObservableVector;
use im::Vector;
use ruma::{api::client::sync::sync_events::v4, events::StateEventType, UInt};
use super::{Error, RoomListEntry, SlidingSyncList, SlidingSyncMode, SlidingSyncState};
use crate::Result;
/// The default name for the full sync list.
pub const FULL_SYNC_LIST_NAME: &str = "full-sync";
/// Builder for [`SlidingSyncList`].
#[derive(Clone, Debug)]
pub struct SlidingSyncListBuilder {
sync_mode: SlidingSyncMode,
sort: Vec<String>,
required_state: Vec<(StateEventType, String)>,
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
full_sync_batch_size: u32,
full_sync_maximum_number_of_rooms_to_fetch: Option<u32>,
send_updates_for_items: bool,
filters: Option<v4::SyncRequestListFilters>,
timeline_limit: Option<UInt>,
name: Option<String>,
state: SlidingSyncState,
rooms_list: Vector<RoomListEntry>,
ranges: Vec<(UInt, UInt)>,
}
impl SlidingSyncListBuilder {
pub(super) fn new() -> Self {
Self {
sync_mode: SlidingSyncMode::default(),
sort: vec!["by_recency".to_owned(), "by_name".to_owned()],
required_state: vec![
(StateEventType::RoomEncryption, "".to_owned()),
(StateEventType::RoomTombstone, "".to_owned()),
],
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
full_sync_batch_size: 20,
full_sync_maximum_number_of_rooms_to_fetch: None,
send_updates_for_items: false,
filters: None,
timeline_limit: None,
name: None,
state: SlidingSyncState::default(),
rooms_list: Vector::new(),
ranges: Vec::new(),
}
}
/// Create a Builder set up for full sync.
pub fn default_with_fullsync() -> Self {
Self::new().name(FULL_SYNC_LIST_NAME).sync_mode(SlidingSyncMode::PagingFullSync)
}
/// Which SlidingSyncMode to start this list under.
pub fn sync_mode(mut self, value: SlidingSyncMode) -> Self {
self.sync_mode = value;
self
}
/// Sort the rooms list by this.
pub fn sort(mut self, value: Vec<String>) -> Self {
self.sort = value;
self
}
/// Required states to return per room.
pub fn required_state(mut self, value: Vec<(StateEventType, String)>) -> Self {
self.required_state = value;
self
}
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
/// When doing a full-sync, this method defines the value by which ranges of
/// rooms will be extended.
pub fn full_sync_batch_size(mut self, value: u32) -> Self {
self.full_sync_batch_size = value;
self
}
/// When doing a full-sync, this method defines the total limit of rooms to
2023-03-16 07:11:45 +00:00
/// load (it can be useful for gigantic accounts).
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
pub fn full_sync_maximum_number_of_rooms_to_fetch(
mut self,
value: impl Into<Option<u32>>,
) -> Self {
self.full_sync_maximum_number_of_rooms_to_fetch = value.into();
self
}
/// Whether the list should send `UpdatedAt`-Diff signals for rooms that
/// have changed.
pub fn send_updates_for_items(mut self, value: bool) -> Self {
self.send_updates_for_items = value;
self
}
/// Any filters to apply to the query.
pub fn filters(mut self, value: Option<v4::SyncRequestListFilters>) -> Self {
self.filters = value;
self
}
/// Set the limit of regular events to fetch for the timeline.
pub fn timeline_limit<U: Into<UInt>>(mut self, timeline_limit: U) -> Self {
self.timeline_limit = Some(timeline_limit.into());
self
}
/// Reset the limit of regular events to fetch for the timeline. It is left
/// to the server to decide how many to send back
pub fn no_timeline_limit(mut self) -> Self {
self.timeline_limit = Default::default();
self
}
/// Set the name of this list, to easily recognize it.
pub fn name(mut self, value: impl Into<String>) -> Self {
self.name = Some(value.into());
self
}
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
/// Set the ranges to fetch.
pub fn ranges<U: Into<UInt>>(mut self, range: Vec<(U, U)>) -> Self {
self.ranges = range.into_iter().map(|(a, b)| (a.into(), b.into())).collect();
self
}
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
/// Set a single range fetch.
pub fn set_range<U: Into<UInt>>(mut self, from: U, to: U) -> Self {
self.ranges = vec![(from.into(), to.into())];
self
}
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
/// Set the ranges to fetch.
pub fn add_range<U: Into<UInt>>(mut self, from: U, to: U) -> Self {
self.ranges.push((from.into(), to.into()));
self
}
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
/// Set the ranges to fetch.
pub fn reset_ranges(mut self) -> Self {
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
self.ranges.clear();
self
}
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
/// Build the list.
pub fn build(self) -> Result<SlidingSyncList> {
let mut rooms_list = ObservableVector::new();
rooms_list.append(self.rooms_list);
Ok(SlidingSyncList {
sync_mode: self.sync_mode,
sort: self.sort,
required_state: self.required_state,
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
full_sync_batch_size: self.full_sync_batch_size,
send_updates_for_items: self.send_updates_for_items,
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
full_sync_maximum_number_of_rooms_to_fetch: self
.full_sync_maximum_number_of_rooms_to_fetch,
filters: self.filters,
timeline_limit: Arc::new(StdRwLock::new(Observable::new(self.timeline_limit))),
name: self.name.ok_or(Error::BuildMissingField("name"))?,
state: Arc::new(StdRwLock::new(Observable::new(self.state))),
fix(sdk): Fix, test, and clean up `SlidingSyncList`. This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
2023-03-15 15:57:29 +00:00
maximum_number_of_rooms: Arc::new(StdRwLock::new(Observable::new(None))),
rooms_list: Arc::new(StdRwLock::new(rooms_list)),
ranges: Arc::new(StdRwLock::new(Observable::new(self.ranges))),
is_cold: Arc::new(AtomicBool::new(false)),
rooms_updated_broadcast: Arc::new(StdRwLock::new(Observable::new(()))),
})
}
}