-
Notifications
You must be signed in to change notification settings - Fork 563
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
Move previous index store to Redux #1919
Conversation
lib/state/ui/middleware.ts
Outdated
@@ -8,7 +8,9 @@ let searchTimeout: NodeJS.Timeout; | |||
|
|||
export const middleware: S.Middleware = store => { | |||
const updateNotes = () => | |||
store.dispatch(filterAction(filterNotes(store.getState()))); | |||
store.dispatch( | |||
filterAction(filterNotes(store.getState()), store.getState().ui.noteIndex) |
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.
What was it needed for here?
If we change the note
reducer to return null
in cases where the note is no longer in the filtered list (instead of using action.notes[0]
) then could we eliminate passing it here? Whereas the <NoteList>
could say "oh, I have a null
note but I have a previousIndex
" and then keep that logic as a render-tie render-time concern?
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.
FILTER_NOTES
gets run on most actions and will clobber any attempt to set the selected note with notes[0] if none is selected. https://github.com/Automattic/simplenote-electron/pull/1919/files#diff-dfb3add3b5c868976c680f25330e1c32L191
If we remove this functionality from the note reducer for FILTER_NOTES
we lose note selection on search when a note no longer exists in the results.
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 have to wonder if it will easier to sort this out sometime down the road when we have more control in the Redux state.
4f331a8
to
eb57255
Compare
Testing
Notes
† these are known existing issues |
In this change we're clearing out the selected note immediate when performing the trash/restore/delete-forever operations to avoid showing an unnecessary interstitial Simplenote logo or the newly-rendered note contents. In addition to clearing out the note state we are immediately triggering a note filter operation to update the note list and avoid a similar awkward in-between state.
Testing
|
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.
Tested and everything seems ship-shape as it relates to this PR. The previous behaviors work as expected. Thanks @belcherj
In #1941 we introduced two regressions and this patch fixes them. - search needs to remember the opened tag and limit results to those matching within that tag. this was overlooked when updating the search query and updating the `filterTags` _from_ that search query - when passing the `filterNotes` action back to the application we have to make sure to pass the previous index. this was lost during the merge of the PR because because the additions from #1919, which fixed the previous regression for it, were deleted as part of moving `ui/middleware` into `search/index` With these changes in place the two regressions should be fixed again.
In #1941 we introduced two regressions and this patch fixes them. - search needs to remember the opened tag and limit results to those matching within that tag. this was overlooked when updating the search query and updating the `filterTags` _from_ that search query - when passing the `filterNotes` action back to the application we have to make sure to pass the previous index. this was lost during the merge of the PR because because the additions from #1919, which fixed the previous regression for it, were deleted as part of moving `ui/middleware` into `search/index` With these changes in place the two regressions should be fixed again.
In #1941 we introduced instant search results. In #1919 and in #1966 we refactored the `previousIndex` into Redux The result was that we weren't resetting the `previousIndex` properly and so on every search we would select _some_ note, often the first one in the list. If this note were large or slow to render then the performance gains we achieved with search were destroyed by the cost of rendering the notes. In this patch we're properly resetting the `previousNote` whenever we actually filter the notes. This means that searches will clear the selected note if it's not in the search results. This also brings back the performance gains we got by refactoring search itself.
In #1941 we introduced instant search results. In #1919 and in #1966 we refactored the `previousIndex` into Redux The result was that we weren't resetting the `previousIndex` properly and so on every search we would select _some_ note, often the first one in the list. If this note were large or slow to render then the performance gains we achieved with search were destroyed by the cost of rendering the notes. In this patch we're properly resetting the `previousNote` whenever we actually filter the notes. This means that searches will clear the selected note if it's not in the search results. This also brings back the performance gains we got by refactoring search itself.
Fix
Moves the previousIndex state from app state to redux. This implementation is mimicking what we were doing in app state and should not be considered a final implementation of how this should be done. One app state is migrated we can take a better look at how to implement this properly.
Also a fix for:
Selects note above recently-trashed note ⭕️ selects top note in list 5
Selects note above recently-restored note in trash view ⭕️ selects top note in list 5
Selects note above recently-deleted-forever note in trash view ⭕️ selects top note in list 5
In #1851 we inadvertently broke this behavior and then in #1895 removed the mechanism that had previously enabled it.
Taken from: #1911 Thanks @dmsnell
Test