Page MenuHomePhabricator

[lib] Update `reduceCurrentUserInfo` to handle `CurrentUserUpdate` payload instead of `ClientAvatar`
ClosedPublic

Authored by atul on May 1 2023, 1:16 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Sep 17, 9:24 AM
Unknown Object (File)
Fri, Sep 13, 1:39 AM
Unknown Object (File)
Sun, Sep 1, 8:53 AM
Unknown Object (File)
Fri, Aug 30, 1:20 PM
Unknown Object (File)
Fri, Aug 30, 1:33 AM
Unknown Object (File)
Tue, Aug 27, 5:40 PM
Unknown Object (File)
Tue, Aug 27, 10:42 AM
Unknown Object (File)
Tue, Aug 27, 6:55 AM
Subscribers

Details

Summary

Depends on D7699


Update reduceCurrentUserInfo on client to update currentUserInfo.avatar based off of update payload instead of ClientAvatar.

Test Plan

Continues to work as expected:

(Need to bump codeversion to 215 for this to work, will make sure I land this diff and codeversion change simultaneously so master is never in a broken state)

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

atul published this revision for review.May 1 2023, 1:23 PM
ashoat added inline comments.
lib/actions/user-actions.js
261 ↗(On Diff #25975)

Let's explicitly return a property of the object rather than the whole thing

lib/types/redux-types.js
939 ↗(On Diff #25975)

Maybe a new type that contains this

This revision is now accepted and ready to land.May 1 2023, 2:00 PM
lib/types/redux-types.js
939 ↗(On Diff #25975)

If we're going to return result.updates (CreateUpdatesResult) in `updateUserAvatar(...), shouldn't we leave this matching?

lib/types/redux-types.js
939 ↗(On Diff #25975)

I think we want to have different types for the keyserver return on the keyserver side vs the payload on the client... the keyserver return will have an optional avatarInfo in there, but the client payload should just be an object that contains a single property, which is updates: CreateUpdatesResult. So basically:

export type UpdateUserAvatarResponse = {
  +avatarInfo?: ClientAvatarInfo,
  +updates?: CreateUpdatesResult,
};
export type UpdateUserAvatarResult = {
  +updates: CreateUpdatesResult,
};

With UpdateUserAvatarResult being both the return of the action function in lib/actions, as wella as the payload used here.

lib/types/redux-types.js
939 ↗(On Diff #25975)

I don't think we need avatarInfo in UpdateUserAvatarResponse? I'm not sure I'm following

On keyserver:

  • For old clients we need to return ?ClientAvatar directly. We can't retroactively wrap it in a UpdateUserAvatarResponse?
  • For new clients we want to return CreateUpdatesResult wrapped in UpdateUserAvatarResponse. There's no need for avatarInfo because it's included in the updates?

I think we need to return ?ClientAvatar | UpdateUserAvatarResult(as UpdateUserAvatarResult is defined above) on the keyserver and type action function return type and payload in redux-types as UpdateUserAvatarResult? I'm not sure we need to do the following:

Let's explicitly return a property of the object rather than the whole thing

in updateUserAvatar?

address feedback (i think)

atul requested review of this revision.May 1 2023, 3:00 PM
atul added inline comments.
lib/actions/user-actions.js
264–268 ↗(On Diff #25983)

If I understood correctly, we want to pull out the fields that exist today (just updates), so that any "new" fields of UpdateUserAvatarResponse don't get included in payload passed to reducers for old clients?

I'm not sure if I understood correctly, so this could be a nonsensical change.

ashoat added a subscriber: inka.

Please address inline feedback and fix CI before landing. Would be great if all of these new types were in avatar-types.js

keyserver/src/responders/user-responders.js
632 ↗(On Diff #25983)

Looks like account-updaters.js was importing this export from here

lib/actions/user-actions.js
254–256 ↗(On Diff #25983)
  1. Can we put this in lib/types/avatar-types.js?
  2. The previous diff introduces a corresponding type for this on the keyserver side, which differs. In that diff I suggested using this name for that type. Thinking about this more, in cases like this we usually have ServerUpdateUserAvatarResponse and ClientUpdateUserAvatarResponse...
264–268 ↗(On Diff #25983)

Yeah exactly! Similar to what @tomek did in response to @inka's feedback here

This revision is now accepted and ready to land.May 1 2023, 3:31 PM

rebase BEFORE addressing feedback

move UpdateUserAvatarResponse alongside UpdateUserAvatarRequest in avatar-types