36 lines
2.1 KiB
Plaintext
36 lines
2.1 KiB
Plaintext
|
|
|||
|
|
已按 BUG-001 的两个子问题改好，修改总结如下。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 子问题 A — 打卡前积分不再提前跳变
|
|||
|
|
|
|||
|
|
- **原逻辑**：点击「立即打卡」后先执行 `uni.navigateTo`，再执行 `this.currentPoints += 30`，在接口返回前就改动了积分。
|
|||
|
|
- **现逻辑**：
|
|||
|
|
- 在 `handleCheckin` 中**不再**在接口成功前修改 `currentPoints`。
|
|||
|
|
- 仅当签到接口调用成功，并且用 `getUserPoints()` 拿到服务端最新积分后，才给 `currentPoints` 赋值（见下）。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 子问题 B — 打卡成功后用服务端积分更新
|
|||
|
|
|
|||
|
|
- **原逻辑**：没有调用任何打卡/签到接口，只在前端写死 `currentPoints += 30`，后端没有参与积分变更。
|
|||
|
|
- **现逻辑**：
|
|||
|
|
1. **调用签到接口**：使用现有接口 `GET /api/front/user/sign/integral`（`@/api/user.js` 中的 `setSignIntegral()`），与需求中的「/api/front/user/checkin 或类似接口」一致，用于触发后端签到与积分累加。
|
|||
|
|
2. **成功后刷新积分**：签到成功后请求 `getUserPoints()`（对应后端 `GET .../tool/points/info`），用返回的积分更新页面。
|
|||
|
|
3. **积分来源**：
|
|||
|
|
`currentPoints` 只从接口赋值：
|
|||
|
|
`pointsRes.data.totalPoints ?? pointsRes.data.points ?? pointsRes.data.availablePoints ?? 0`
|
|||
|
|
不再使用硬编码的 +30。
|
|||
|
|
4. **错误与跳转**：若签到或拉取积分失败，会 `uni.showToast` 提示并 `return`，不跳转；只有成功后才 `uni.navigateTo('/pages/tool/checkin-publish')`。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 其它修改
|
|||
|
|
|
|||
|
|
- **loadCheckinData**：积分取值改为优先使用服务端字段，与上面一致：
|
|||
|
|
`currentPoints = pointsRes.data.totalPoints ?? pointsRes.data.points ?? 0`
|
|||
|
|
这样列表和打卡页的积分都来自服务端。
|
|||
|
|
|
|||
|
|
需求里提到的「GET /api/front/user/info」在当前项目里没有对应接口；用户积分接口是 `GET /api/front/tool/points/info`（`getUserPoints()`），因此用该接口的返回值刷新并赋值给 `currentPoints`。若后续后端提供 `/api/front/user/info` 并返回积分，只需在成功后再调该接口，用其返回的积分更新 `currentPoints` 即可。
|