zulip/zulip-mobile

Make use of the new `is_muted` property (equals not in_home_view)

Open

#3,285 opened on Jan 16, 2019

View on GitHub
 (3 comments) (0 reactions) (0 assignees)JavaScript (673 forks)github user discovery
api migrationshelp wanted

Repository metrics

Stars
 (1,348 stars)
PR merge metrics
 (PR metrics pending)

Description

No immediate action is required, but this is a notification for the mobile team about an API upgrade for stream muting we've been doing in https://github.com/zulip/zulip/pull/10220. It's completely backwards-compatible and should merge in the next day or so.

Historically, you knew whether a stream was muted by looking at the in_home_view property of the Subscription object, which is pretty confusing as a name. Now, in page_params and other routes that fetch subscription objects, we send both in_home_view and is_muted, where is_muted always equals not in_home_view (and is a sane name for the thing that tells you whether a stream is muted). A legacy client should work fine by just ignoring the is_muted key, but ideally we'll want to migrate our code to use the is_muted key rather than in_home_view for readability (and eventually, we may stop sending for in_home_view entirely).

Additionally, a client can, when muting/unmuting a stream, pass the is_muted property rather than in_home_view. Whether that option is available can be determined by whether the is_muted property appears in the Subscription dicts (or the version cutoff for the next zulip/zulip release, if one wants to do it that way).

To avoid breaking backwards compatibility, right now when a stream is muted/unmuted by a client, the events system event we send is still just an in_home_view event because the structure of those events doesn't naturally support specifying two values. We might add a redundant one for is_muted before merging; I'll update this issue with notes on that after doing a bit more thinking about it.

Contributor guide