You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The two stream maps are different ways of reaching the same objects; but the subscription objects are separate. Subscription objects have all the information that's on the corresponding ZulipStream, so this is duplicative, and raises the possibility of them getting out of sync; keeping them in sync is an invariant we need to maintain.
The duplication reflects what the server API gives us in the initial snapshot — there's both streams and subscriptions, and the items in the latter duplicate all the information that's in the corresponding items of the former. But within our code we should give ourselves just one copy of the stream information.
This came up on a call between me and @sirpengi a couple of weeks ago, and in #382 he took one step toward this, which was to make our Subscription type extend ZulipStream. That will let us have a data structure with a type like Map<int, ZulipStream> where for streams we're subscribed to, the value is a Subscription. It'll take a bit of playing with it to keep the API that's exposed to the rest of the app a convenient one, though. I plan to experiment with that sometime after Beta 1 is out.
The text was updated successfully, but these errors were encountered:
Currently on PerAccountStore we have the following data structures:
The two stream maps are different ways of reaching the same objects; but the subscription objects are separate. Subscription objects have all the information that's on the corresponding ZulipStream, so this is duplicative, and raises the possibility of them getting out of sync; keeping them in sync is an invariant we need to maintain.
The duplication reflects what the server API gives us in the initial snapshot — there's both
streams
andsubscriptions
, and the items in the latter duplicate all the information that's in the corresponding items of the former. But within our code we should give ourselves just one copy of the stream information.This came up on a call between me and @sirpengi a couple of weeks ago, and in #382 he took one step toward this, which was to make our
Subscription
type extendZulipStream
. That will let us have a data structure with a type likeMap<int, ZulipStream>
where for streams we're subscribed to, the value is aSubscription
. It'll take a bit of playing with it to keep the API that's exposed to the rest of the app a convenient one, though. I plan to experiment with that sometime after Beta 1 is out.The text was updated successfully, but these errors were encountered: