Smoother typing experience on the desktop app? #2172
Comments
|
Hi @s1-en, does this relate to the length of the note at all? We're already looking at some performance improvements under the hood. The issues I'm aware of are mostly related to longer notes. |
|
Hi @codebykat, it seems to affect new blank notes as well (as I tested above) but it gets way more apparent as the note gets longer |
|
I noticed this too. Looking at the network tab on my browser dev tools, I noticed it's making a request for a 1px gif every single time I enter a character, presumably for analytics. That seems like overkill. Disabling analytics increases performance by a lot, though it's still not perfect. This is what it looks like with analytics enabled: And this is what it looks like with analytics disabled: Notice how it stutters a lot less when analytics is disabled. |
|
So then how did you disable the analytics image? @mmaluff |
|
For testing I was just setting
|
|
Can folks on this thread test out the beta app at https://staging.simplenote.com and report back if performance seems better? Thanks 😄 |
|
With analytics turned off, the performance is actually perfect, exactly as I'd hope (and much better than on the current app). With analytics turned on, it's still just as bad as today (and still seems to do the thing where it gets the 1px gif for every character I enter). |
|
That's good to know, thanks! I'll investigate the analytics. It should be queueing up note edits which I would expect to also debounce the analytics tracking, but obviously not. |
|
@mmaluff We were unable to reproduce the lag from analytics over here (which doesn't necessarily mean anything). Anyhow we just pushed an update to staging.simplenote.com that limits how frequently those analytics calls get made on a note edit. Can you let me know if you can re-enable analytics now without degraded performance? |
|
It looks fantastic! No noticeable difference between analytics on or off
now. Thank you!!
…On Fri, Aug 21, 2020 at 6:00 PM Kat Hagan ***@***.***> wrote:
@mmaluff <https://github.com/mmaluff> We were unable to reproduce the lag
from analytics over here (which doesn't necessarily mean anything). Anyhow
we just pushed an update to staging.simplenote.com that limits how
frequently those analytics calls get made on a note edit. Can you let me
know if you can re-enable analytics now without degraded performance?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2172 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAG7VZIPGTNUQBSZCXXS7QTSB34AFANCNFSM4OKY7E4Q>
.
|
co-authored by @belcherj and @codebykat with design work by @SylvesterWilmott ## Description We've been unable to resolve the worst sync bugs in the application and feature development has been artificially limited by the fact that we have to fight a number of data-flow issues tightly coupling different levels of the application's architecture together. In this branch, we're ripping apart the entire app state and Simperium data flow to rebuild it in order to remove a number of those couplings and races. This commit changes most of the app and was rolled out in staging to test the changes. We're also replacing `draft-js` with `Monaco` which is almost as big of a change conceptually as changing the state. Moving to `Monaco` allows us to remove a copy of the note data from the app and allows us to maintain a fully-synchronous update cycle, eliminating a race condition between the Simperium copy of the data, the app copy, and the contents in the text buffer. ## Major code changes - The interface between `node-simperium` and this app has been moved into Redux state and out of `indexedDB`. The `indexedDB` interface as asynchronous and led to sync issues under a variety of race conditions with the network data, remote updates, browser tab scheduling, whether the browser was focused or hidden behind other windows, and more. The new synchronous interface guarantees that updates occur when we expect them to occur and therefore will be updated by the time we continue processing changes and updates from the server. - `Monaco`'s synchronous plaintext interface allows us to extend the atomic "all updates occur together and instantaneously" paradigm to the text buffer. By sharing the note data in the text editor, in the app, and in `node-simperium`, we will guarantee that we won't accidentally apply new edits to old data. - In many cases we have been dispatching multiple actions in order to perform one real action. For example, edit a note and then clear out the search state. Because these presented intermediate states for the app, partial updates, they have been removed. Now we have created new Redux actions for these real actions and app state has been adjusted so that each kind of data has its own reducer and those reducers listen to all the actions which could affect them. Now we will see a single dispatch that multiple reducers listen to instead of dispatching one action type for each reducer. - The Simperium connection has been moved into a new centralized middleware. All Simperium interactions take place in this middleware and are no longer woven into the app. This allows the app to update so that there's only ever one copy of a note's data and it's always up to date with the text editor. This resolves longstanding issues with the note list showing expired data. It also allows us to model the Simperium connection as a reactive system that responds to changes in the app and injects new events from the server in a way that's independent from local operation. This has dramatically simplified many different subsystems. - The persistence layer has now been created as a separate subsystem from before, when it was integrated with the Simperium code. It now operates as a kind of background worker that persists the Redux state into `indexedDB` and stores the entire contents atomically. Previously, integrated into the note bucket, the persistence layer would update each note, ghost, and bucket value separately leading to mismatches between a note and the base version it was built from, leading to sync issues. - So-called "prop drilling" has been replaced by connecting components in the React tree to state. This was done to simplify the interfaces around the app. It was previously difficult to understand what exactly was executing with the `onAction` props because there wasn't a clear way to walk up the component tree in an editor without resorting to text searching. Any `onEdit` type actions have been replaced with `dispatchProps` that directly dispatch the intended actions. ## Related or fixed issues ### Defects Resolves #2171 (note display doesn't update height immediately upon change from menu bar) Resolves #2074 (floating IME on Korean input) Resolves #2014 (when opened note changes so it's not in the search, it still stays open) Resolves #1953 (when renaming tag, update in search bar if tag opened) Resolves #1942 (can't easily select start of note content) Resolves #1887 (renaming a tag removes it from a note) #### Cursor position and movement Resolves #2085 (cursor jumps to new note) Resolves #2035 (cursor hidden at bottom of note) Resolves #1595 (restore cursor position when flipping between edit/preview mode) Resolves #1477 (cursor jumping in Windows) #### Synchronization Resolves #1938 (not restoring tags when reverting to an earlier revision) Resolves #1641 (updates to a tag in one session don't update in other sessions until they reload) Resolves #1640 (infinite duplication of tag name when editing tag) Resolves #1562 (content not syncing) Resolves #1520 (only syncing one note at a time/per session) Resolves #1291 (quirky unsynced changes info) Resolves #502 (data loss when editing simultaneous with iOS) Resolves #459 (show note sync indicator) #### Force-sync #1897 #800 #### Ghost-Writing Resolves #2030 Resolves #1787 ### Enhancements Resolves #2162 (mostly - additional syncing metadata for notes) Resolves #1836 (remove `app-state`) Resolves #1816 (confusing revision history ordering) #1537 (add indicator to show syncing status) Resolves #2036 (logging-out in one sessions logs out all sessions) Resolves #1410 (logout is buried in app settings and hard to find) #### Private Mode #1924 - functionality in Firefox private mode other than offline persistence ### Performance Resolves #2172 (slow app) Resolves #501 (slow loading large notes) ### Deprecations Resolves #2117 (audit use of draftJS) Resolves #1762 (decorator performance in draftJS) Resolves #1026 (use of `token` in `localStorage` in `boot.js`) ### Possibly - check these #1698 (problems with Korean input and lists at start of note) #1619 (buggy Japanese IME conversion) #1572 (RTL languages - checked tasks moving to the right) #1511 (missing characters on Korean IME conversion) #1456 (slow, possibly 4K-resolution-related)
Please, be as descriptive as possible. Issues lacking detail, or for any other reason than to request a feature, may be closed without action.
What (Required)
Make the typing experience on the desktop application (Windows) feel smoother. See the following comparisons: between Simplenote and VS code. Both are Electron-based.
VS Code: https://i.imgur.com/0NHBfEQ.mp4
Simplenote https://i.imgur.com/u4UrN9o.mp4
In addition to the visual sluggish feel, there's a small delay between keypress and it appearing on the app which adds to the whole unresponsive feel.
Why (Required)
Right now, it feels slow to respond while typing.
How (Optional)
I'm not sure what's causing the slowdown, could it be the network checking? (In the case of collaborations) If that's the case then may I suggest having a check first if the note is being edited simultaneously by different people before turning it on? If it's a wholly unrelated issue then please disregard my ignorant statement.
The text was updated successfully, but these errors were encountered: