-
Notifications
You must be signed in to change notification settings - Fork 560
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
Open new note upon creation #1582
Conversation
onNewNote: content => { | ||
dispatch(search({ filter: '' })); | ||
dispatch(newNote({ noteBucket, content })); | ||
onNoteOpened(); |
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.
huh. would it be worth creating a new semantic action for this? onNoteOpened()
leaves me flabbergasted when trying to understand what it's supposed to be doing. on the other hand, some action like openNote()
, better openNoteView()
, or something else that makes sense could clear it up some. is it worth the extra steps intros PR? not sure.
of note, onNoteOpened
updates state to isNoteOpen: true
which ends up being passed around and then sets a CSS class name - nothing else.
seems like we can go back to some of the naming troubles at the time and realize we lack a few simple terms to describe the views.
further, is there any time we would want to create a new note without opening up the note editor view? we've passed this prop down through the UI hierarchy but we're already calling newNote()
in app-state
- we could also listen for that action in app-state
and also update the current view.
for previous work see https://github.com/Automattic/simplenote-electron/pull/443/files#diff-ad1834ceae17437ce4883908cceeb573
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.
My concern is that doing so will take us down a path that will require an large effort and significant refactor that is not within the scope of this sprint.
I used the existing method for opening the note: https://github.com/Automattic/simplenote-electron/blob/develop/lib/note-list/index.jsx#L172
I would like to clean up the redux and flux state but should we stall this fix till that can be completed?
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's fine as long as we acknowledge it. it caught my eye because of the duplicated logic and the hard time I have knowing what "onNoteOpened" should mean.
👍
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.
100% agree
4bdab80
to
ff6f530
Compare
In (#1582) CHANGELOG.md was renamed to RELEASE-NOTES.txt. This caused the link to the release notes to break.
Update the link to the Release Notes in the updater config In (#1582) CHANGELOG.md was renamed to RELEASE-NOTES.txt. This caused the link to the release notes to break.
* Update dependency concurrently to v5 (#1631) * Update dependency electron-rebuild to v1.8.6 (#1533) * Update dependency highlight.js to v9.15.10 (#1545) * Update dependency autoprefixer to v9.6.4 (#1628) * Update dependency react-overlays to v2 (#1620) * Update dependency react-dropzone to v10.1.10 (#1630) * Update dependency eslint-config-prettier to v6.4.0 (#1629) * Update dependency eslint-plugin-react to v7.16.0 (#1623) * Update react monorepo to v16.10.2 (#1621) * Update dependency electron to v4.2.11 (#1483) * Refactor tag operations to stop directly mutating tag objects (#1638) See #1614 As part of a broader effort to resolve data-flow issues in the app this PR is a first step in removing direct mutation where transactional atomic updates should be occurring. It's not clear if the existing code is the source of existing defects in the software and this is part of why the code is problematic; we have created inherent concurrency flaws that open up extremely-difficult-to-reproduce bugs. Resolving this may or may not resolve any existing bugs but it will definitely help guard us from introducing new ones. --- Previously we have been directly mutating note and tag objects when editing those tags. This mutation can lead to concurrency defects which expose themselves as inconsistent UI state. This breaks our Redux model which assumes that all UI updates happen atomically. In this patch we're building new note objects and tag objects when we make these updates in order to maintain our consistency. --- There should be no significant visual or behavioral changes with this PR. We are changing code related to removing tags, renaming tags, and reordering tags. In testing verify that with separate sessions the updates appear as expected. Add, reorder, and remove tags to make sure the changes synchronize. * Refactor updating note content to stop directly mutating note object (#1634) See #1614 As part of a broader effort to resolve data-flow issues in the app this PR is a first step in removing direct mutation where transactional atomic updates should be occurring. It's not clear if the existing code is the source of existing defects in the software and this is part of why the code is problematic; we have created inherent concurrency flaws that open up extremely-difficult-to-reproduce bugs. Resolving this may or may not resolve any existing bugs but it will definitely help guard us from introducing new ones. --- Previously we have been directly mutating the note object when updating its content. This may have been an attempt to work around confusing data-flow issues that thankfully don't exist anymore. We have also been performing inline checks to make sure that we update the editor's contents if we receive these updates. This mutation can lead to concurrency defects which expose themselves as inconsistent UI state. This breaks our Redux model which assumes that all UI updates happen atomically. In this patch we're building a new note object when we update a note in order to maintain our consistency. In light of #1598 we're also removing some work-around code that attempted to force consistency when it didn't exist; that consistency now exists since we're tracking the underlying Simperium data closely now vs. storing it in separate places. When updating checklist items we're forcing a sync so that those changes will propagate immediately. We don't have a need to debounce those clicks. * Refactor note tag operation to stop directly mutating note object (#1639) See #1614 As part of a broader effort to resolve data-flow issues in the app this PR is a first step in removing direct mutation where transactional atomic updates should be occurring. It's not clear if the existing code is the source of existing defects in the software and this is part of why the code is problematic; we have created inherent concurrency flaws that open up extremely-difficult-to-reproduce bugs. Resolving this may or may not resolve any existing bugs but it will definitely help guard us from introducing new ones. --- Previously we have been directly mutating note objects when editing their tags. This mutation can lead to concurrency defects which expose themselves as inconsistent UI state. This breaks our Redux model which assumes that all UI updates happen atomically. In this patch we're building new note objects when we make these updates in order to maintain our consistency. --- There should be no significant visual or behavioral changes with this PR. We are changing code related to removing tags, renaming tags, and reordering tags. In testing verify that with separate sessions the updates appear as expected. Add, reorder, and remove tags to make sure the changes synchronize. * Fix: Broken oAuth flow (#1627) We have been experiencing problems when trying to login with the WordPress.com signin. Something appears to have changed in Electron such that the older versions of the app still work but newer versions are failing. In this patch we're rewriting the authentication flow to simplify it and prepare ourselves for better handling of the failure cases. In production we are seeing strange behaviors on failure and some on success: unending re-requests to `simplenote://auth` which trigger full CPU load; and no response after authentication. After this patch we should be able to wrangle in errors and add a timeout to better communicate when things are failing. Additionally, the unending loop should be closed due to a replacement of the old network intercept code with a single simplified model. We have also been sharing sessions between the main window and the auth window and also sharing sessions between teach time the auth window appears. This leads to leaked cookies and can result in confusing flows, largely because of the shared cookies. In this patch we're creating a new `Session` for the auth window every time we open it. By not including `persist:` in the "partition" name we're making sure it only exists in memory. By introducing randomness into its name we're making sure we don't share the same session from one auth attempt to the next. By freeing the window after close we're making sure we don't leak memory. Previously we were able to open the auth window after closing it and instead of logging in again it would open to the "Accept/Deny" view. After this change it requires logging in on every attempt. This will likely be more frustrating but much safer than the previous behavior. * Make system setting the default theme preference (#1581) * Make system setting the default theme preference * Update Release Notes * Make system the first item in the list * Update system theme logic * Add option to hide menu bar (#1215) Closes #293 Based on #1216 This adds an option to auto-hide the menu bar on Windows/Linux Electron. The option will be in Settings ▸ Display. screen shot 2019-02-21 at 23 26 17 We have to be careful not to get the user stuck in a situation where they can't bring back the menu bar, so we'll show the Settings button and footer links in the Navigation Bar when auto-hide is enabled. * Support the unicode bullet as a list item bullet in unordered lists (#1551) Support the unicode bullet character • as a list item bullet because lists copied from HTML or word documents may contain this character. * Add release note adding bullet char to lists (#1646) * Note list: Distinguish loading from empty states (#1650) Alternative idea to #1649 There are a few times when we boot the app and our list of notes is empty because we haven't received udpates from the server yet. This happens on intial app boot, immediately after authorizing, and when we lose our local copy of the notes from `IndexedDB`. During these times we're showing that there are no notes in the account which is misleading. In this patch we're starting with a `null` value for the notes so that we can distinguish between "there are no notes in the account" and "we haven yet to determine which notes are in the account." In comparison to #1649 we're using a tri-state value for `notes` instead of introducing an additional flag which must be kept in sync with `notes`. * Deps: Update simperium to fix infinite duplication bug Update `simperium` library to incorporate changes that fixed a defect where we were holding open old WebSocket connections after signing-out and signing-in. This defect produced an infinite duplication of changes. * Update the link to the Release Notes in the updater config (#1675) Update the link to the Release Notes in the updater config In (#1582) CHANGELOG.md was renamed to RELEASE-NOTES.txt. This caused the link to the release notes to break. * In Dev mode, open CHrome Deve Tools in detached mode (#1660) * Update version in package.json for 1.10.0 release Added the beta version for 1.10.0-beta1 release * Fix/only run notes loaded when notes loaded (#1680) * Only run notesLoaded when notes are indeed loaded After querying the noteBucket we run notes loaded with an empty notes array. This causes havoc because we rely on notes being null until notes are loaded. This commit adds a check to ensure there is at least one note before running notesLoaded * Add release notes * Update RELEASE-NOTES.txt * Update signing certificate (#1682) Props to @loremattei for creating these changes * Bump version to v1.10.0-beta2 (#1684) * Add version for release 1.10.0
Fix
#1566
This PR updates the logi so that clicking new note not only creates that note but opens it. This was only a problem on smaller screens where only the note or the note list show.
Test
Review
Only one developer is required to review these changes, but anyone can perform the review.
Release
RELEASE-NOTES.txt
was updated with: