-
-
Notifications
You must be signed in to change notification settings - Fork 654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
model: Make REGISTER_COMPLETE reset some state we forgot about #5613
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing these! Small comments below.
fetchingReducer( | ||
deepFreeze({ [HOME_NARROW_STR]: { older: false, newer: false } }), | ||
deepFreeze({ ...eg.action.message_fetch_start, narrow: SEARCH_NARROW('some query') }), | ||
), | ||
).toEqual(prevState); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This argument to fetchingReducer
is meant to be prevState
, right? (In order to express that we're ignoring this action.)
test('REGISTER_COMPLETE', () => { | ||
expect( | ||
[ | ||
{ type: MESSAGE_FETCH_START, narrow: HOME_NARROW, numBefore: 10, numAfter: 10 }, | ||
eg.action.register_complete, | ||
].reduce(fetchingReducer, eg.baseReduxState.fetching), | ||
).toEqual(eg.baseReduxState.fetching); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as at #5612 (comment) .
src/topics/topicsReducer.js
Outdated
case RESET_ACCOUNT_DATA: | ||
|
||
// Reset to clear stale data; payload has no initial data for this model | ||
case REGISTER_COMPLETE: // eslint-disable-line no-fallthrough | ||
return initialState; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's probably clearer to just have two cases here:
case RESET_ACCOUNT_DATA: | |
// Reset to clear stale data; payload has no initial data for this model | |
case REGISTER_COMPLETE: // eslint-disable-line no-fallthrough | |
return initialState; | |
case RESET_ACCOUNT_DATA: | |
return initialState; | |
case REGISTER_COMPLETE: | |
// Reset to clear stale data; payload has no initial data for this model | |
return initialState; |
It's true that the implementation of the two cases is the same; but that one line isn't much code to duplicate.
And as the comment indicates, the reason why the two different action types lead to that result are different. So it's cleanest to think about them separately, and not try to make a common abstraction they share.
src/chat/fetchingReducer.js
Outdated
// Reset just because `fetching` is server-data metadata, and we're | ||
// resetting the server data it's supposed to apply to… but really, if | ||
// there's an in-progress message fetch now, it's a bug, perhaps #5609. | ||
// TODO(#5609): Remove "perhaps #5609" when that specific bug is fixed. | ||
case REGISTER_COMPLETE: // eslint-disable-line no-fallthrough |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed at #5609 (comment) just now, I think it's actually fine for there to still be an ongoing fetch up to this point.
There's still the issue that even though we reset this state to say there's no longer an ongoing fetch, there may still be an ongoing fetch even after this point. That's #5609. But even if there is one, I think we probably don't want to be showing loading indicators for it in the UI, so it's right to be resetting state.fetching
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we do cancel the fetches, we can do a MESSAGE_FETCH_ABORT
or some-such action so that state.fetching
should be all false
when REGISTER_COMPLETE
comes along, right, what do you think?
That way it's more transparent that a given fetch has false
in state.fetching
because we aborted that fetch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, that seems reasonable. We'll see what feels cleanest when we get to that point, I guess.
408d9ca
to
5100434
Compare
Thanks for the review! Revision pushe.d |
5100434
to
5a40b00
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Looks good except one comment below — please go ahead and merge after fixing.
}); | ||
const prevState = typingReducer(initialState, action1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should also have a line checking prevState
is not equal to initialState
, right? Like with fetchingReducer
above.
This addresses the second item in the list at zulip#5605: > - [ ] `REGISTER_COMPLETE` should reset or replace all server data > and server-data metadata, but it isn't in some cases: > - server data: `topics`, `typing` (should reset) > - server-data metadata: `fetching` (should reset) Although, I've left a comment on `fetchingReducer`, where doing so felt a bit funny because morally it shouldn't be necessary. Fixes-partly: zulip#5605
5a40b00
to
77b7e9c
Compare
Thanks for the review! Done. |
This addresses the second item in the list at #5605:
Although, I've left a comment on
fetchingReducer
, where doing sofelt a bit funny because morally it shouldn't be necessary.
Fixes-partly: #5605