Page MenuHomePhabricator

[lib] Move inconsistencies finding into specs
ClosedPublic

Authored by tomek on Oct 4 2023, 3:19 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 1, 4:32 AM
Unknown Object (File)
Fri, Nov 1, 3:47 AM
Unknown Object (File)
Oct 2 2024, 11:35 AM
Unknown Object (File)
Oct 2 2024, 11:35 AM
Unknown Object (File)
Oct 2 2024, 11:35 AM
Unknown Object (File)
Oct 2 2024, 11:35 AM
Unknown Object (File)
Oct 2 2024, 11:35 AM
Unknown Object (File)
Oct 2 2024, 11:30 AM
Subscribers

Details

Summary

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

Test Plan

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

Repository
rCOMM Comm
Branch
redux-update-spec
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

Return the same empty array ref

lib/shared/state-sync/current-user-state-sync-spec.js
24–26 ↗(On Diff #31626)

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 ↗(On Diff #31626)

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 ↗(On Diff #31626)

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 ↗(On Diff #31626)

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.

tomek requested review of this revision.Oct 4 2023, 3:42 AM

LGTM, only one nit: you can probably replace Array<> with $ReadOnlyArray.

This revision is now accepted and ready to land.Oct 5 2023, 5:25 AM
In D9354#275219, @kamil wrote:

LGTM, only one nit: you can probably replace Array<> with $ReadOnlyArray.

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.

In D9354#275224, @kamil wrote:
In D9354#275219, @kamil wrote:

LGTM, only one nit: you can probably replace Array<> with $ReadOnlyArray.

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.

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.

Use read only types in all the specs