Skip to content
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

api: Sync updateStream and createStream with their API docs #5341

Merged
merged 16 commits into from
Apr 19, 2022

Conversation

chrisbobbe
Copy link
Contributor

@chrisbobbe chrisbobbe commented Apr 18, 2022

After #5339, on the path to fixing #5250.

Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @chrisbobbe! Generally this looks good. Comments below.

Comment on lines 332 to 334
export type Stream = {|
// Based on the getStreams response, current to FL 121:
// https://zulip.com/api/get-streams#response
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm interesting. How does this compare with the type we see on streams in the /register response?

The objects we actually get from the server and treat as Stream are from there.

Copy link
Contributor Author

@chrisbobbe chrisbobbe Apr 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just checked, and it's identical in all these properties, thank goodness. I'll update the comment and commit message.

Copy link
Contributor Author

@chrisbobbe chrisbobbe Apr 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's identical in all these properties, thank goodness.

Still, though, could even not mention GET /streams, right? If we start using GET /streams, we'll want to check the doc again at that time, to be sure, anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's identical in all these properties, thank goodness.

Still, though, could even not mention GET /streams, right? If we start using GET /streams, we'll want to check the doc again at that time, to be sure, anyway.

Yeah, seems right.

Comment on lines 14 to 19
// Adapt to a server API change that was accidentally incompatible:
// https://github.com/zulip/zulip-mobile/pull/4748#issuecomment-852254404
// https://github.com/zulip/zulip-mobile/issues/4747#issuecomment-946362729
// TODO(#4659): Ideally this belongs inside `api.updateStream`.
// TODO(server-4.0): Simplify this (if it hasn't already moved.)
// See implementation comments in api.updateStream.
getZulipFeatureLevel(state) >= 64 ? value : JSON.stringify(value);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This new comment seems not specific enough to find what it's referring to and be sure you've found the thing that was intended -- there are a lot of comments on api.updateStream now 🙂

Perhaps mention it's specifically the comment on description and new_name?

Hmm, also the new comment seems backward. The issue is that old servers required the superfluous JSON.stringify; new servers require that the parameter be simply the desired string.

Comment on lines 18 to 20
// TODO(server-4.0): For these two, it's no longer acceptable to give
// the server values without `JSON.stringify`ing them first. There was
// a server API change that was accidentally incompatible:
// https://github.com/zulip/zulip-mobile/issues/4747#issuecomment-946362729
// https://github.com/zulip/zulip-mobile/pull/4748#issuecomment-852254404
description?: $PropertyType<Stream, 'description'>,
new_name?: $PropertyType<Stream, 'name'>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think perhaps the simplest solution for this comment is to say:

Suggested change
// TODO(server-4.0): For these two, it's no longer acceptable to give
// the server values without `JSON.stringify`ing them first. There was
// a server API change that was accidentally incompatible:
// https://github.com/zulip/zulip-mobile/issues/4747#issuecomment-946362729
// https://github.com/zulip/zulip-mobile/pull/4748#issuecomment-852254404
description?: $PropertyType<Stream, 'description'>,
new_name?: $PropertyType<Stream, 'name'>,
// TODO(#4659): Once we pass the feature level to API methods, this one
// should encapsulate a switch at FL 64 related to these two parameters.
// See call sites.
description?: $PropertyType<Stream, 'description'>,
new_name?: $PropertyType<Stream, 'name'>,

and delete the TODO-4659 comment on the method as a whole -- i.e. effectively move it here -- and then leave the comment at the call site unchanged.

Then for other things that should be encapsulated, a one-line comment like
// TODO(#4659): Encapsulate this.
can suffice, because the TODO-server comments already explain what changed between versions. I think that means is_announcement_only and 'forever'?

Comment on lines 23 to 24
// TODO(server-5.0): New in FL 53
is_web_public?: $PropertyType<Stream, 'is_web_public'>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean FL 98 here?

Comment on lines +42 to +45
// TODO(server-3.0): Replaced in FL 1 by 'stream_post_policy'.
// Commented out because this isn't actually in the doc. It probably
// exists though? Copied from api.updateStream.
// is_announcement_only?: $PropertyType<Stream, 'is_announcement_only'>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, curious.

chrisbobbe and others added 16 commits April 19, 2022 10:59
…ties

Instead of up to three in sequence, one per changed property.
…logic

We'll be adding more stream properties here soon, and it'll be best
to avoid multiplying the number of different names.
One for stream attributes, and one for miscellaneous options.

The create-stream API is a little awkward in that it piggy-backs on
the subscribe-to-stream API. Here's the doc:
  https://zulip.com/api/create-stream

> You can create a stream using Zulip's REST API by submitting a
> [subscribe](/api/subscribe) request with a stream name that
> doesn't yet exist and passing appropriate parameters to define the
> initial configuration of the new stream.

So, make our code a bit clearer by bundling the attributes of the
to-be-created stream into an object. We're about to add more
attributes, to sync with the API doc.

While we're at it, order the attributes by their appearance in the
doc.
…inding

I think the only good reason to have such fallback code at this
layer would be that we don't trust the server to use reasonable
fallbacks itself.

There are certainly awkward things about this endpoint -- it's doing
double duty as "subscribe-to-stream" and "create-a-stream" -- but I
see no reason to distrust the server's defaults for these params,
which set attributes on a created stream. Its choices currently
match ours, but they could reasonably change, and we'd be fine
deferring to the server if they did.

NFC because, currently, this binding's only caller also applies the
same fallbacks. That might be a bad choice, but at least now that
choice isn't forced by the code that's designed to interface
directly with the server.
With similar reasoning as in the previous commit, except these are
in `options` instead of `streamAttributes`.

This time, one of the properties doesn't have a default applied by
the single caller: `announce`. So this is a behavior change: we're
now sometimes omitting `announce`, which lets the server decide what
behavior to fall back on. Currently, it's documented as falling back
to `false` (and that should apply for all non-ancient servers):
  https://zulip.com/api/subscribe#parameter-announce
This seems like a fine place to let the server control the behavior,
and it's documented to give the same behavior anyway. See
  https://zulip.com/api/subscribe#parameter-announce :

> […] If not provided, then the requesting user/bot is subscribed.

We can start passing `principals` again when we eventually have a UI
for choosing multiple users to be subscribed, as the web app does.

For now, it's redundant and unnecessary for us to request the same
behavior the server would give anyway. Especially since we're asking
for it in a way that's discouraged: we use an email instead of a
user ID.
Grepping shows that we actually use this in several places now.
@chrisbobbe
Copy link
Contributor Author

chrisbobbe commented Apr 19, 2022

Thanks for the review! Revision pushed.

@gnprice
Copy link
Member

gnprice commented Apr 19, 2022

Thanks! Looks good -- merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants