-
Notifications
You must be signed in to change notification settings - Fork 47
Backend improvements #660
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
base: main
Are you sure you want to change the base?
Backend improvements #660
Changes from all commits
15338e3
454cc74
e0b9765
ea05fe0
ca239f0
5797ff8
ae2f597
5b3d3b5
e1f73db
b05eaf3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,9 +1,9 @@ | ||
| import 'package:commet/client/components/photo_album_room/photo.dart'; | ||
|
|
||
| abstract class PhotoAlbumTimeline { | ||
| Stream<int> get onAdded; | ||
| Stream<int> get onChanged; | ||
| Stream<int> get onRemoved; | ||
| Stream<Photo> get onAdded; | ||
| Stream<Photo> get onChanged; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A potential issue with not being able to get the index of where the change happened, means the UI always has to rebuild the entire list, and can't just update a single widget. It would make it harder to use things like
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Rebuilding an entire list is the same time complexity as removing a list element as an index, updating a list using indexes is extremely slow already. At worst (animated list) it's the same complexity as before, at best it's one order faster.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also would recommend talking about the notifying list change in here : #647 They are the same commits. It make it easy to only include that change, as it is more of a bugfix on synchronization that "code quality" change. |
||
| Stream<Photo> get onRemoved; | ||
|
|
||
| List<Photo> get photos; | ||
|
|
||
|
|
||
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.
I'm not sure I agree that making ClientManager a singleton is necessarily beneficial. with it being a top level variable, it's already globally scoped but has the addition of being nullable. while in most cases its safe to assume the ClientManager has been initialized, in the instances where it isn't being able to use the
?or!operators is much nicer than having to check something likeClientManager.isInitializedand I would prefer to hit a null operator error, as opposed to having it silently fail when I've assumed ClientManager is initialized, but it hasn't actually been.There are conditions where ClientManager should not be null and uninitialized, for example updating notifications in the background
Uh oh!
There was an error while loading. Please reload this page.
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.
Oups, i expected it was always initialized, my bad on this one, tho i still think it's cleaner as a static element maybe have it as static nullable then.