Summary:
fix(subject-field): Fix subject text field focus
Before, if you clicked a mailto link, once the composer loaded, the subject field (which was focused in composer-preload) blurred. This was not ideal as users would want to type once the popout loaded and instead they would have to click first. We identified that this was coming from the composer header _renderSubject injected component. We fixed the focus within mail merge subject text field and additionally added the onComponentDidChange method to injected component. This allowed us to only update the component when the header field changed.
Test Plan: tested on my machine for mailto links
Reviewers: juan
Reviewed By: juan
Subscribers: juan
Differential Revision: https://phab.nylas.com/D3150
Summary: When you would click outside the contenteditable in the composer, it would focus to the absolute end. Not ideal. I added a check if the click is above the top of the content editable -- if you click the top padding of it -- then focus at the beginning.
Test Plan: is this something i should test?
Reviewers: juan
Reviewed By: juan
Subscribers: juan
Differential Revision: https://phab.nylas.com/D3139
Summary: We used to parse the quoted text on each keystroke in the composer for a reply so that we could continue to determine what was quoted text. However, that resulted in dramatically slow typing for replies to complex HTML emails. Now, the quoted text isn't a part of the reply until `prepareDraftForSyncback`, after all of the extensions have run their transformations—we use a marker to determine whether quoted text should be appended or not. The quoted text control is now a one-way operation—you can't hide the quoted text after showing it (Gmail-style).
Test Plan: Tested locally (but didn't run unit tests because they won't run on my machine...)
Reviewers: bengotow, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3106
Summary:
Refactored signature preferences page to allow more signatures than the previous 1-1 mapping for signatures and accounts. Created a multi select dropdown of the accounts for which a certain signature is set as default for. Added a button into the draft header From field to toggle between saved signatures.
refactor(signatures): Add basic add/remove capabilities to static
refactor(signatures): Hooked up signature actions and signature store for basic functionality
fix(signatures): Cleaned up signature store and started on multiselectdropdown
fix(signatures): Add multi signature toggle select to multiselect dropdown
build(signatures): Built framework for multiselect dropdown
build(signatures): Toggle button functionality for dropdown
build(signatures): Build multi select from components and add debounce
refactor(signatures): Move signature actions and signature store into flux
fix(signatures): Styled composer signatures button/dropdown and fixed preferences checkmarks
build(signatures): Finish main functionality, about to refactor composer signature button into injected component
fix(signatures): Changed position styles
fix(signatures): Fixed background color for dropdown button when blurred
build(signatures): Began to write tests for signatures store, preferences and dropdown
Test Plan: Wrote tests for preferences signatures, signature store, signature composer dropdown and refactored tests for signature composer extension. For signature composer extension I removed applyTransformsToDraft and unapplyTransformsToDraft and tested by sending emails with signatures to different providers to make sure the <signature> tag caused problems.
Reviewers: bengotow, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3073
Summary:
- Fixes several selection and focus issues along the way
- Can now preview what tokens will look like when not editing
- Adds decorator to listen to mail merge session changes and removes a bunch of duplicated code
- Gets rid of all imperative code (and specs) that had to imperatively
reach into the dom to update the tokens
Test Plan: - Unit tests
Reviewers: bengotow, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2989
Summary:
This diff introduces several updates to mail merge to improve the procedure for sending a list of drafts.
Specifically, sending mass email will now:
- Clear mail merge metadata on the drafts that will actually be sent
- Upload attached files only /once/, and reuse those files on the drafts that will actually be sent
- Minimize database writes for new drafts being created
- Will queue a SendManyDraftsTask that will subsequently queue the necessary SendDraftTasks and keep track of them, and notify of any failed tasks
TODO:
- Add state to MailMerge plugin for failed sends and ability to attempt to re send them
Test Plan: - TODO
Reviewers: evan, bengotow, jackie
Reviewed By: bengotow, jackie
Subscribers: jackie
Differential Revision: https://phab.nylas.com/D2973
Summary:
SEE ASSOCIATED SUBMODULE DIFF
This enables rich React components (like the Scheduler's `NewEventCard`)
to be used in contenteditables.
We introduce the concept of an "Overlaid Component". These are rendered
React components that are absolutely positioned on top of an equivalent
"Anchor" in a contenteditable.
Inside the contenteditable are special `<img />` tags that have an
id corresponding to a particular rich overlaid component. This way, even
if those img tags are cut and pasted or moved, they'll have a mapping to a
particular component stored in the `OverlaidComponentStore`. Img tags
are fairly well handled natively by contenteditable and allow you to
maniuplate these overlaid components as normal text elements.
The `OverlaidComponentStore` is responsible for listening to and managing
the state of the Anchors and their equivalent OverlaidComponents.
We use a decorator called `ListenToChanges` that allows us to wrap
components to update their corresponding anchor. Since we need to know
about ALL changes that could affect rendered height and width, we need to
use a `MuatationListener` instead of the React render cycle.
This is only the initial diff. There are several TODOs here:
https://paper.dropbox.com/doc/Composer-Overlaid-Components-FoZrF0cFggzSUZirZ9MNo
Test Plan: TODO. Manual
Reviewers: juan, bengotow
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2946
Summary:
- Simplify undoManager to just maintain the undo/redo history items
- DraftEditingSession manages snapshotting state of draft, hack allows it to also save selection (still hoping to eventually put selection in body HTML as markers)
- Switch from `debounce` to `throttle` style behavior so typing for along time followed by undo doesn't undo away your entire block.
This resolves two issues:
+ Changes to participant fields are no longer undoable because they go straight to the session.
+ Changes to metadata weren't undoable.
Test Plan: Tests WIP
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2956
Summary:
Add basic globally accessible performance monitoring.
Allows us to measure load times for composer windows (or whatever else we
want) and view the data as a Histogram on Mixpanel
Test Plan: manual
Reviewers: bengotow, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2965
Summary:
Adds ability to drop tokens in subject via a custom rendered subject field which
renders a contenteditable instead of an input.
Decided to completely replace the subject field via injected components for a
few resons:
- That's the way we are currently extending the functionality of the participant fields, so it keeps the plugin code consistent (at the cost of potentially more code)
- Completely replacing the subject for a contenteditable means we hace to do extra work to clean up the html before sending.
- Reusing our Contenteditable.cjsx class for the subject is overkill, but using a vanilla contenteditable meant duplicating a bunch of the code in that class if we want to add
Test Plan: Unit tests
Reviewers: bengotow, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2949
Summary:
- Add some docs to Table components
- Updates Table components to use a TableDataSource instead of accessing arrays, cleans up code a bit
- Add enzyme lib to have a cleaner and simpler api to write tests for React Components
- Updates decorators to extend from the BaseComponent instead of vanilla Component, this way instance methods are still available on composed components
Test Plan: - Unit tests
Reviewers: evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2941
- This prevented emoji selection via the popover from working on a new
window because the plugin is loaded after the contenteditable sets up
the action listeners, so we need to re set them on update
Summary: Adds CSV imports, proper styles to mail merge plugin and fixes a handful of bugs
Test Plan: TODO
Reviewers: bengotow, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2925
Summary:
Keymaps & menus CSON => JSON, remove AtomKeymaps, CommandRegistry use of CSS selectors, use Mousetrap instead
Important Notes:
- The `application:` prefix is reserved for commands which are handled in the application process. Don't use it for other things. You will not receive the events in the window.
- Maintaining dynamic menus seems to come with quite an overhead, because Electron updates the entire menu every time. In the future, we'll need https://github.com/electron/electron/issues/528 to really make things nice. I will be tracking this upstream.
- The format for keyboard shortcuts has changed. `cmd-X` is now `command+shift+x`
Test Plan: Run tests
Reviewers: juan, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2917
Summary:
Adds Mail Merge Plugin
- Adds new table components to component kit
- Adds new extension points to allow dragging and dropping into composer contenteditable and participant fields and customizing participant fields
- Adds new decorators and other misc updates
- #1608
Test Plan: TODO
Reviewers: bengotow, evan
Reviewed By: bengotow, evan
Differential Revision: https://phab.nylas.com/D2895
Summary:
This diff is designed to dramatically speed up new window load time for
all window types and reduce memory consumption of our hot windows.
Before this diff, windows loaded in ~3 seconds. They now boot in a couple
hundred milliseconds without requiring to keep hot windows around for
each and every type of popout window we want to load quickly.
One of the largest bottlenecks was the `require`ing and initializing of
everything in `NylasExports`.
I changed `NylasExports` to be entirely lazily-loaded. Drafts and tasks
now register their constructors with a `StoreRegistry` and the
`TaskRegistry`. This lets us explicitly choose a time to activate these
stores in the window initalization instead of whenever nylas-exports
happens to be required first.
Before, NylasExports was required first when components were first
rendering. This made initial render extremely slow and made the proposed
time picker popout slow.
By moving require into the very initial window boot, we can create a new
scheme of hot windows that are "half loaded". All of the expensive
require-ing and store initialization is done. All we need to do is
activate the packages for just the one window.
This means that the hot window scheme needs to fundamentally change from
have fully pre-loaded windows, to having half-loaded empty hot windows
that can get their window props overridden again.
This led to a major refactor of the WindowManager to support this new
window scheme.
Along the way the API of WindowManager was significantly simplifed.
Instead of a bunch of special-cased windows, there are now consistent
interfaces to get and `ensure` windows are created and displayed. This
DRYed up a lot of repeated logic around showing or creating core windows.
This also allowed the consolidation of the core window configurations into
one place for much easier reasoning about what's getting booted up.
When a hot window goes "live" and gets populated, we simply change the
`windowType`. This now re-triggers the loading of all of the packages for
the window. All of the loading time is now just for the packages that
window requires since core Nylas is there thanks to the hot window
mechanism.
Unfortunately loading all of the packages for the composer was still
unnaceptably slow. The major issue was that all of the composer plugins
were taking a long time to process and initialize. The solution was to
have the main composer load first, then trigger another window load
settings change to change the `windowType` that loads in all of the
plugins.
Another major bottleneck was the `RetinaImg` name lookup on disk. This
requires traversing the entire static folder synchronously on boot. This
is now done once when the main window loads and saved in a cache in the
browser process. Any secondary windows simply ask the backend for this
cache and save the filesystem access time.
The Paper Doc below is the current set of manual tests I'm doing to make
sure no window interactions (there are a lot of them!) regressed.
Test Plan: https://paper.dropbox.com/doc/Window-Refactor-UYsgvjgdXgVlTw8nXTr9h
Reviewers: juan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2916
