Notifications now check to see the thread they are supposed to open
exists.
Also, clean up FocusedContentStore._onFocus so that it doesn't have the side
effect of dispatching another action and messay logic.
Instead, added Actions.ensureCategoryFocused, to focus any category, and which
should be used separately from focusing content (notifications now use
this action for "opening" the thread)
Also, convert FocusedPerspectiveStore to ES6
Summary: Initial support for inline images. Tests still forthcoming!
Test Plan: WIP
Reviewers: mark, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3295
Summary:
We originally didn't do this because creating a DOM tree was loading images.
Using range.createContextualFragment seems to do it without the tree ever
being attached.
Accompanying changes to src/pro are here:
https://phab.nylas.com/D3300https://github.com/nylas/edgehill/compare/bengotow/draft-dom-transformations?expand=1
Also rename applyTransformsToDraft => applyTransformsForSending. Needed
a new name because the function signature has changed. AFAIK there are no
open source plugins using the old functions.
Test Plan: All specs updated
Reviewers: evan, juan
Reviewed By: evan, juan
Differential Revision: https://phab.nylas.com/D3299
Summary:
Each file downloaded would open finder and show the path to the file. Users were reporting that this felt excessive when downloading multiple files all to the same location #1044. I added a check to see if the path was the same as the previous file path, and only showed the item in the folder if these differed.
Also added tests for this in file download store.
test(downloads): Add tests for showing item in folder only if lastDownloadDirectory differs
Test Plan: Added tests to file-download-store-spec
Reviewers: bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D3121
A previous commit (ad04775) added an fdescribe() to one of the tests in
draft-helpers-spec. This changes that to a regular describe() so that
all tests will be run when running ./N1 --test.
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:
Moves all reading / writing of config file to the main process,
to avoid needing to write code to lock across processes. This should also
be more efficient than re-loading the file in all processes when it's
saved.
Test Plan: Run tests
Reviewers: evan, jackie
Reviewed By: evan, jackie
Differential Revision: https://phab.nylas.com/D2963
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