-
-
Notifications
You must be signed in to change notification settings - Fork 654
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
users reducer: Handle all user updates from realm_user op: update #5386
Conversation
This will let us do an `else if`.
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 @chrisbobbe! This looks great; tiny comment below, and a workaround for that Flow issue.
src/users/usersReducer.js
Outdated
return { ...user, ...event.person }; | ||
} else { | ||
return user; |
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.
We still keep the behavior of only allowing avatar_url and role
changes to apply to the state [1]. […]
[1] Because we've been wary of accepting server data that we haven't
vetted; see 729655187.
And indeed we can now see that was well justified -- with the nice new type definitions, there are two kinds of these events where the properties don't actually line up with properties on the user!
@@ -51,22 +52,15 @@ describe('usersReducer', () => { | |||
|
|||
/** | |||
* Check that an update event with supplied `person` works. |
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.
nit: describe('EVENT_USER_UPDATE'
should update, e.g. to "EVENT > realm_user > update"
// TODO: Try to make `user_id` optional again. | ||
const check = (person: $PropertyType<RealmUserUpdateEvent, 'person'>) => { |
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 have a fix for this, which I showed you in the office. Here's a try-flow link for the exploration we did of this Flow issue.
Following the generic "server event" pattern Greg started in 979d283. We still convert avatar_url to our special AvatarURL form at the edge, in eventToAction, for crunchy shell: https://github.com/zulip/zulip-mobile/blob/master/docs/architecture/crunchy-shell.md Also, give a Flow type to the event itself as we receive it from the server: RealmUserUpdateEventRaw. We should keep this up-to-date with the server API documentation. (We also have RealmUserUpdateEvent, for the slightly processed form that has AvatarURL.) We still keep the behavior of only allowing avatar_url and role changes to apply to the state [1]. But now, that code is in usersReducer instead of eventToAction. For the reducer tests that simulate actions changing *other* user data, that means they'd now fail. So, skip them, with a plan to re-enable. [1] Because we've been wary of accepting server data that we haven't vetted; see 7296551. The API doc seems to have been improved since then, and now we've written down a type for it. So now we can proceed more confidently, which is nice!
06f6200
to
d287d32
Compare
Revision pushed! Please hold off merging until I've done some manual testing, but you can look at the revision in the meantime if you want. |
// Excluded: "When the owner of a bot changes." The `users` state | ||
// doesn't include cross-realm bots. | ||
test.skip('When the owner of a bot changes.', () => { | ||
check({ user_id: theUser.user_id, bot_owner_id: (theUser.bot_owner_id ?? 1) + 1 }); |
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.
nit: this and the rest of this commit still introduce setting user_id, then that's cut in a later commit
// TODO: Follow changes in the user's email address, whether while we're | ||
// event polling or not. | ||
email: string, |
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 also went and added a mention of this case on #3408.
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!
The reducer still doesn't handle all these cases, so we can't un-skip them yet. But now at least we're prepared to cover all the cases once the reducer *does* handle them, soon. See the list of cases in the doc: https://zulip.com/api/get-events#realm_user-update The removed comment was wrong to say that we should exclude a test for bot-owner changes. The users state doesn't include cross-realm bots, it's true. But it does include regular bots, and those are the bots that have owners.
6487d01
to
50c55a8
Compare
Thanks! Revision pushed, with the results of my manual testing: zulip/zulip#22103, and a commit at the tip that follows from that. |
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! The revision looks good, with one nit below. Please merge at will.
src/users/usersReducer.js
Outdated
// This assertion is cumbersome. But it fills a | ||
// gap in Flow's coverage…that apparently Flow | ||
// doesn't announce by marking anything with | ||
// `any`. Remove when doing so doesn't stop Flow | ||
// from catching something wrong on | ||
// `value` or `rendered_value`. | ||
}: $Values<$NonMaybeType<$PropertyType<User, 'profile_data'>>>), |
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.
nit: I like to mark situations like this with something like FlowIssue
(no $
) in the comment. That helps in finding it, either for a broad sweep for issues we've run into in Flow (perhaps to consider dropping the workarounds after a Flow upgrade occasionally?)… or for finding a specific issue one is thinking of but doesn't remember precisely where we encountered it.
See zulip/zulip#22103, which I sent after observing that this was sometimes null.
50c55a8
to
5dc4770
Compare
Thanks for the review! Merged, with that tweak. |
It's really exciting to see this! |
Glad to hear it, Tim! You might also be excited to see that we've finally got round to #4933. |
And, to get there (and also just because it's good practice), write down with a Flow type what exactly we expect to get from servers in this event.
In particular, this is on the path to correctly resolving #5250, as well as #2900 / #5363, which are server release goals.
Replaces: #3403
Related: #3408