Move the code and do required changes in some types.
Depends on D9319
https://linear.app/comm/issue/ENG-4677/describe-inconsistencies-as-a-part-of-a-spec
Details
Details
Added console logs in the reports reducer and in the user reducer. Modified server state and checked if state sync generates a report.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- redux-update-spec
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| lib/shared/state-sync/current-user-state-sync-spec.js | ||
|---|---|---|
| 24–26 | Introducing this function isn't great, but is really convenient. Without this function in this spec, we would need to mark it as optional in StateSyncSpec which would require checking if the function is defined before calling it in all the other reducers. | |
| lib/shared/state-sync/entries-state-sync-spec.js | ||
| 57–61 | We're expecting just ProcessServerRequestAction action, which lets us read action.payload.calendarQuery here instead of passing it using the fourth parameter - like we were doing previously. | |
| 92 | In the original code, we were returning the same, empty array in some reducers. This diff makes this consistent by returning the same ref in all the specs. | |
| lib/types/redux-types.js | ||
| 781 | We find inconsistencies only when reducing PROCESS_SERVER_REQUESTS action. Because of that, we can type our functions to accept just ProcessServerRequestAction as an action instead of BaseAction. This lets us create a more consistent interface, by reading action.payload.calendarQuery inside entries spec, instead of passing calendarQuery as a fourth parameter. | |
Comment Actions
On the other hand, when you return the result we should allow the caller to do and modify the result, not sure what is better in this use case.
Comment Actions
It seems like in this case we definitely should return a read-only type. When there are no inconsistencies, we return the same reference and we don't want it to be modified by anyone.