Summary: This is mostly config changes.
Test Plan: Tested the Google OAuth flow.
Reviewers: bengotow, drew
Reviewed By: bengotow, drew
Differential Revision: https://phab.nylas.com/D2907
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
Office 365 likes to format email addresses as follows:
Last Name, First Name (Some Description) <email@address.org>
This causes Contact.firstName() (and hence sometimes displayName()) to return
"Last Name," which looks a bit odd in the message/thread views.
The intent of the commit is to correctly parse these names so that (using the
above example):
- firstName = "First Name"
- lastName = "Last Name (Some Description)"
- fullName = "First Name Last Name (Some Description)"
These behavioral changes only impact names containing a ','.
I don't know that this really provides exhaustive coverage of Office 365, and
keeping the description as part of the last name is not completely guilt free,
but it's not any worse than the previous state of affairs which also has
the description in the same field but combined instead with (misplaced)
first name data.
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:
Adds an activity list view that shows message opens and link clicks in a
chronological feed.
TODO: Add badge for unread notifications and different styling for read/unread
notifications. Click item to jump to corresponding thread.
Test Plan: TODO.
Reviewers: evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2915
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
Hopefully fixes#1991
I don't have N1 setup locally, so this is a blind shot–would appreciate somebody who has it set up to pull this and verify this fixes the issue, but as far as I can tell it should.
The gist is:
> Looking at the code, what you do is use the `search/users` endpoint to find users by email and taking the repos from there. You then load the repositories of the username, but we can't sort those by most-starred: "sort string Can be one of `created`, `updated`, `pushed`, `full_name`. Default: `full_name`" *([src](https://developer.github.com/v3/repos/#list-user-repositories))*
> What we could instead do is use the search API, which **allows us to search for repositories by a specific user and sort by most starred**. This is a tiny bit hacky, but works perfectly fine. E.g. this is the URL for my most starred repos: `https://api.github.com/search/repositories?q=user:mxstbr&sort=stars&order=desc`
