-
Notifications
You must be signed in to change notification settings - Fork 309
api: Rename ApiNarrowStream
to ApiNarrowChannel
#847
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
Conversation
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.
Thanks @Khader-1!
This looks good to me, moving on to integration review.
7d3fbd6
to
4da6c62
Compare
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.
class ApiNarrowStream extends ApiNarrowElement { | ||
class ApiNarrowChannel extends ApiNarrowElement { | ||
@override String get operator => 'stream'; |
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.
An instance of an ApiNarrowElement subclass represents a narrow filter:
https://zulip.com/api/construct-narrow
and generally the subclass ApiNarrowFoo represents narrow filters with the operator "foo".
Here, we're going to want to start representing the operator "channel" and sending that to the server instead of "stream". That's a bit tricky because we can't say "channel" to a server that doesn't understand it, i.e. one older than feature level 250. We've successfully handled the same thing for the pm-with
to dm
operator; see ApiNarrowDm
and its subclasses.
I think I don't want to rename this class without doing that handling, though — I feel like that will make it harder for us to notice that that's something we still need to do. So I'll close this PR for now.
(This is different from the situation with parts of the API that are about data we receive. For those, generally the server is still sending the old name and there's nothing for us to do yet toward speaking the new name with the server; the next steps are on the server side. Here, the server accepts both the old and the new name, so it's done what it can and the next steps are entirely on the client side, for us to start sending the new name instead of the old.)
Fixes parts of #631