Stage 17 round 6 (#16/#17, PR C): lobby sort + server-derived in-game friend state
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 8s
CI / integration (pull_request) Successful in 11s
CI / ui (pull_request) Successful in 31s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m19s
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 8s
CI / integration (pull_request) Successful in 11s
CI / ui (pull_request) Successful in 31s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m19s
Lobby: group the my-games list into your-turn / opponent-turn / finished (empty sections hidden), ordered by last activity (your-turn oldest-first, the other two newest-first), as a compact line-separated list. gameDTO and FB GameView gain last_activity_unix (turn start while active, finish time once finished); a pure lib/lobbysort.ts holds the grouping/ordering. Friends: the in-game 'add to friends' item is now server-derived via a new GET /user/friends/outgoing (+ friends.outgoing op), returning addressees with a pending OR declined request (both read as 'request sent'), so it is correct across reloads; it shows a disabled '✓ in friends' once accepted. It live-updates when the opponent answers: RespondFriendRequest now publishes friend_added (accept) / friend_declined (new notify sub-kind, decline) to the original requester, whose open game re-derives its friend state. Tests: lobbysort unit test; gateway outgoing + last_activity transcode tests; backend integration ListOutgoingRequests + respond-publishes-to-requester; e2e updated for the new lobby section labels + a non-friend active opponent. Docs: ARCHITECTURE notify catalog, FUNCTIONAL(+ru) lobby/friends, PLAN.
This commit is contained in:
@@ -25,6 +25,12 @@ type IncomingListResp struct {
|
||||
Requests []AccountRefResp `json:"requests"`
|
||||
}
|
||||
|
||||
// OutgoingListResp is the addressees the caller has already requested (a live pending
|
||||
// request or one the addressee declined) and cannot re-request.
|
||||
type OutgoingListResp struct {
|
||||
Requests []AccountRefResp `json:"requests"`
|
||||
}
|
||||
|
||||
// FriendCodeResp is a freshly issued one-time friend code.
|
||||
type FriendCodeResp struct {
|
||||
Code string `json:"code"`
|
||||
@@ -134,6 +140,14 @@ func (c *Client) ListIncoming(ctx context.Context, userID string) (IncomingListR
|
||||
return out, err
|
||||
}
|
||||
|
||||
// ListOutgoing returns the addressees the caller has already requested (pending or
|
||||
// declined) and cannot re-request.
|
||||
func (c *Client) ListOutgoing(ctx context.Context, userID string) (OutgoingListResp, error) {
|
||||
var out OutgoingListResp
|
||||
err := c.do(ctx, http.MethodGet, "/api/v1/user/friends/outgoing", userID, "", nil, &out)
|
||||
return out, err
|
||||
}
|
||||
|
||||
// IssueFriendCode issues a one-time friend code for the caller.
|
||||
func (c *Client) IssueFriendCode(ctx context.Context, userID string) (FriendCodeResp, error) {
|
||||
var out FriendCodeResp
|
||||
|
||||
Reference in New Issue
Block a user