-
Notifications
You must be signed in to change notification settings - Fork 565
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
Update note: user needs to switch to another one, and go back to get the updated result #1879
Labels
bug
Something isn't working
Comments
dmsnell
added a commit
that referenced
this issue
Feb 4, 2020
Resolves #1879 It appears that we removed a flow in #1851 which updated app state in response to updates from the note editor[1]. While this didn't impact the operation of the editor it did present itself as a bug when previewing markdown-rendered notes. The editor is stateful on its own and so continued to function independently of the state of the selected note's content. The preview, however, grabs the contents of the selected note whenever it's activated and then renders those into a DOM node. This means that it showed the old contents of the note unless you navigated to another note and back, which swapped out the selected note with the new updated contents. In this patch, which currently is probably wrong in some way, we're updating the selected note when calling `onChangeContent` so that we don't get out of sync with the data sources. Hopefully at the end of our state cleanup and stabilization project this will disappear but for now this fix catches the gap that left split data sources. Probably there were other bugs we didn't discover as a result of this. Mainly we need to test and audit for traces of cycles/loops in the update so that we don't start spinning or overwriting data we just entered. In my brief testing the easy cases worked as I expected them to simply and singly. [1]: https://github.com/Automattic/simplenote-electron/pull/1851/files#diff-3c87750a7cc32e0127447ffc78f5c0d5L300
Thanks @surfer0627 - it appears that some changes we're making (to stabilize the platform) introduced this without us noticing. Should be fixed soon! |
@dmsnell |
This was referenced Feb 5, 2020
dmsnell
added a commit
that referenced
this issue
Feb 6, 2020
* Fix: Update selected note when making changes in the editor view Resolves #1879 It appears that we removed a flow in #1851 which updated app state in response to updates from the note editor[1]. While this didn't impact the operation of the editor it did present itself as a bug when previewing markdown-rendered notes. The editor is stateful on its own and so continued to function independently of the state of the selected note's content. The preview, however, grabs the contents of the selected note whenever it's activated and then renders those into a DOM node. This means that it showed the old contents of the note unless you navigated to another note and back, which swapped out the selected note with the new updated contents. In this patch, which currently is probably wrong in some way, we're updating the selected note when calling `onChangeContent` so that we don't get out of sync with the data sources. Hopefully at the end of our state cleanup and stabilization project this will disappear but for now this fix catches the gap that left split data sources. Probably there were other bugs we didn't discover as a result of this. Mainly we need to test and audit for traces of cycles/loops in the update so that we don't start spinning or overwriting data we just entered. In my brief testing the easy cases worked as I expected them to simply and singly. [1]: https://github.com/Automattic/simplenote-electron/pull/1851/files#diff-3c87750a7cc32e0127447ffc78f5c0d5L300 * Handle tag updates too by always re-selecting note on updates from the server When tags were being updated in the pap they also came through this function but they weren't coming through `onUpdateContent`, meaning that our fix overlooked tags and probably also system tags and the like. In this patch we're no longer selectively updating the note if it has a remote patch (indicating that it came from another device). Instead, we're always updating and selectively setting `hasRemoteUpdate` based on that knowledge. This ensures that we maintain consistency with local updates.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce:
Actual behavior:
Unable to update note.
Expected behavior:
Note updated successfully.
(Now, note xxx updated successfully.
System configuration:
Windows version:
6.1.7601 service pack 1
Name and version of other software in use when reproducing the issue:
screen reader: NVDA 2019.2.1
The text was updated successfully, but these errors were encountered: