Summary:
This commit converts list-tabular to JS, and in the process re-adds shouldComponentUpdate which had been previously removed (D3837).
This time, shouldComponentUpdate will correctly check if actual data to render has changed, as opposed to checking if `itemPropsGenerator` had changed.
Test Plan: manual
Reviewers: halla, spang, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3839
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
Summary:
We need to wait for the `DraftEditingSession` to set it's draft before we can
pass it to the composer. I've modified these tests to properly wait for the
draft promise. Additionally, I removed the `DraftStore.isSendingDraft()` stub
so we run the actual logic for determing if a draft can be sent. We had some
tests with this stub, but then we had other tests that made sure it worked
without the stub, and I don't see why we don't just run the tests without the
stub to begin with. I added a stub to `@session.ensureCorrectAccount()`
to get around issues with committing the draft's change set.
Test Plan: Ran the suite!
Reviewers: evan, juan
Reviewed By: evan, juan
Differential Revision: https://phab.nylas.com/D3834
Summary: This is a pretty small diff – it changes the snooze-store to save metadata for the individual messages affected instead of for the whole thread. We need this to have snoozing work without running an actual sync of the whole mailbox.
Test Plan: WIP.
Reviewers: evan, halla
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3815
Summary: Just a quick fix to remove the warning in the console
Test Plan: manual
Reviewers: mark
Reviewed By: mark
Differential Revision: https://phab.nylas.com/D3823
Summary:
We were mostly ignoring errors in our delta streaming connections. This
commit makes it so that if we get an authentication error from n1Cloud we mark the
account as invalid so users know to re authenticate, and can properly receive metadata deltas
If the error is not an authentication error, it automatically retries
the delta connection.
Addresses T7744
Test Plan: manual
Reviewers: evan, spang, halla
Reviewed By: halla
Differential Revision: https://phab.nylas.com/D3813
Summary:
We weren't properly keeping track of the focus state in the ComposerView which
would cause us to lose track of what was focused when plugins were eventually
loaded.
Test Plan: Run locally, verify that we don't lose focus
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3801
Summary:
This animation was changing the width of the after pseudoelement, which was
causing a lot of repainting and layout to occur in the very bottom corner of
the screen. This in turn caused an idle window to use 50-70% CPU all the
time during initial sync. The fix is to change the after element to three
spans and modify the animation to alter their opacity which avoids having to
do style and layout reflows due to width changes. It also looks slightly cooler
IMHO :-) An idle main window now sits around 8% CPU on my laptop.
Test Plan: Run locally, verify that CPU is lower.
Reviewers: evan, juan
Reviewed By: juan
Subscribers: halla
Differential Revision: https://phab.nylas.com/D3810
Summary:
Previously we were only debouncing one function in onContentChanged. This would
cause us to do very expensive things on every keypress in the things that
weren't debounced. This diff changes things so that we debounce the entire
process of running the spellchecker.
Test Plan:
Run locally, make sure spellchecker doesn't run on every keypress.
Misspell lots of things, type really quickly, paste large chunks of text
into the composer.
Reviewers: evan, spang, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3791
Summary:
Users who only had a custom imap account could not open the window to
add a custom imap account the first time the auth was opened, rendering
the app useless for them.
Github issue #3185 and T7691
Test Plan: manual
Reviewers: halla, spang, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3783
Summary:
Sometimes you have to perform a query that needs to do a table scan. For those
times you don't want to silence entire classes of queries (e.g. by table name),
you can now silence individual queries.
Test Plan: Run locally, verify that noisy stuff disappears from logs
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3763
Summary:
This removes `refreshHealthOfAccounts`, which I originally found because I
was trying to refactor it out of the IdentityStore. We need it gone from
the IdentityStore so that store can trigger frequently as things like the
usageLimits constantly update on it.
This also fixes T7520 where we'd get `ECONNREFUSED 127.0.0.1:2578` on
launch unnecessarily.
The concept of refreshing the health of accounts by occassionally polling
the /accounts endpoint is obsolete. This depends on
D3769 which entirely removes the /accounts endpoint
from K2.
Account health is pushed to us by `Actions.updateAccount` which is fired
directly from the main local-sync sync loop.
This also removes `refreshAccounts` and `Actions.refreshAllDeltaConnections`. These were fired by the Identity Store whenever it updated. We no longer need the Identity Store to tell us to reset the delta connections with our local-sync accounts. The delta connections will either be reset by our offline notification button, or when adding or removing an account. The Identity Store was a redundant mechanisms
Test Plan:
Manually verify things work with an existing account. Add a new account
and ensure sync starts. Remove an account and ensure it gets cleaned up.
Reviewers: halla, khamidou, mark, juan
Reviewed By: juan
Maniphest Tasks: T7520
Differential Revision: https://phab.nylas.com/D3770
Summary:
This diff is a rename. No logical changes.
We used to have a set of files called `nylas-sync-worker`. In Old N1 these
used to have a lot of logic to slowly sync mail from our API. Since we
exclusively use local-sync via a soon-to-be-obsolesced delta stream, these
files really just manage the delta streaming connection.
It's incredibly confusing to have a set of files called worker-sync when
there's a sync-worker already in the codebase. This renames everything to
refer to them as account sync workers.
The reason I wanted this rename is because the IdentityStore on initial
launch triggers and fires a fairly scary-sounding
`Actions.refreshAllSyncWorkers()`. In reality all it does is
`Actions.refreshAllDeltaConnections()`. I'm also tired of staring at files
for a full minute before realizing that this is not the sync worker I was
looking for.
Test Plan:
After rename, booted the app and ensured that deltas were coming through
for new mail and no errors were being thrown
Reviewers: halla, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3767
Summary:
Previously, when adding an account, we waited for it to be completely loaded (which meant having fetched the folder list) before focusing it on the sidebar. This could take several seconds, so it made the app feel unresponsive or slow when adding an account.
Then, we changed the logic to wait an arbitrary amount of time to focus the newly added account in the sidebar, with the hope that it would be enough time to focus it correctly but that it wouldn't seem too long. This still caused the unwanted effect of focusing it before it had been fully loaded.
This commit changes the auth flow so that the onboarding shows a Success page until the newly added account is fully loaded, and only /then/ closes itself, focuses the main window, and allows the account to be correctly focused in the sidebar.
Test Plan: manual
Reviewers: halla, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3751
Summary:
This diff modifies the SearchIndexer class to handle limiting the search
index size. It does this by periodically re-evaluating the window of
the n most recent items in a particular index where n is the max size of
the index. It then unindexes the items which are marked as indexed but
are no longer in the window and indexes the things that are in the window
but aren't marked as indexed.
Test Plan:
Run locally with a reduced thread index size, verify that the index
includes the most recent items and that it is the correct size. Also verify that
the queries used properly use fast sqlite indices.
Reviewers: evan, juan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3741
Summary:
When the search index got very big the queries we were running during
after keypress would cause jank in the UI which was very noticeable on
subsequent keypresses. This diff backgrounds these queries and adds a
LIMIT to the fts MATCH clauses to avoid having to send too much stuff
across the IPC bridge.
Test Plan: Run locally, make sure that typing is smooth while searching
Reviewers: juan, evan
Reviewed By: juan, evan
Differential Revision: https://phab.nylas.com/D3757
Summary: See title
Test Plan: tested locally
Reviewers: juan, mark, evan
Reviewed By: juan, mark
Subscribers: juan
Differential Revision: https://phab.nylas.com/D3744
Summary:
- Add a new button to the sync error notification to "Debug" sync. This will open the activity window and dev tools in that window. Depends on D3736
- Update the "Contact Support" link in error notifications to prepopulate the support ticket with the sync error in the account
- Make the "Check Again" button react when clicking it
Test Plan: manual
Reviewers: evan, khamidou
Reviewed By: evan, khamidou
Differential Revision: https://phab.nylas.com/D3737
Summary:
- Make the try again button react when clicked
- Don't mark as offline until after we've tried again at least 3 times
Test Plan: manual
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3738
Summary:
- Refactor Gmail auth functions
- Add Analytics in
- Show error states
Depends on D3735
Test Plan: manual
Reviewers: khamidou, juan
Reviewed By: khamidou, juan
Differential Revision: https://phab.nylas.com/D3732
Summary:
We changed the index format (splitting participants into to and from) so
we need to update the index version so that it gets rebuilt.
Test Plan: Run locally, make sure index gets rebuilt
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3728
Summary:
Previously we indexed all participants together for a single thread.
This lead to confusing search results when people would search for
'from' and get back lots of results that were only 'to'. This diff
splits the participants index into separate to and from indices and
updates the query generator appropriately.
Fixes T7580
Test Plan: Run locally, verify from doesn't return to and vice versa.
Reviewers: evan, juan
Reviewed By: juan
Maniphest Tasks: T7580
Differential Revision: https://phab.nylas.com/D3724
Summary:
If we don't have IMAP settings for a particular email domain,
try to choose based on which provider was selected instead.
Fixes#3168
Test Plan: tested locally
Reviewers: spang, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3721
Summary:
Some strange scenario is causing us to attempt to redefine the object property `_delta` on our `delta.attributes` object inside `DeltaProcessor._decorateDeltas`, which throws an error, and consequently throws the app into an error loop. I haven't been able to track down how to reproduce this, but when it happens it completely takes the app down.
From testing with tomasz's copy of N1, this seemed to have originated from the lack of Account tokens, which was hard to discover because the `_deltas` object completely floods the console with errors.
From what I gather, `_decorateDeltas` is only called from a single place, `DeltaProcessor.process`, which is also only called from a single place, and its unclear how it would be called multiple times with the same delta object references.
In order to prevent this error from completely destroying the app, I've added the `configurable` option when defining the property, so that redifining it doesn't throw an error. It should be safe to redefine this property with the latest delta reference, and will also allow us to discover other errors more easily in the console like the lack of account tokens which might be the original cause of this problem.
Test Plan: manual
Reviewers: mark, spang, evan, halla
Reviewed By: evan, halla
Differential Revision: https://phab.nylas.com/D3717
Summary:
Makes these messages update even if the user doesn't force a
re-render by switching perspectives.
Test Plan: tested manually
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3715
Summary:
We had to add the id to the index as well (along with is_search_indexed)
so that the query worked correctly since it sorts by id. Also added a
default value of 0 for boolean attributes so that we don't have to query
for two different values (0 and null), which was causing sqlite to have to
do a final b-tree sort which is slow.
Test Plan: Run locally, verify query plan with EXPLAIN QUERY PLAN
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3712
Use staging autoupdater for staging.
fixed failing test
Fix autoupdater – we were using the wrong command.
Revert "Bump version to 1.5.0"
Temporarily reverting this because I need to test the upgrade path from
0.4.2 => 1.5.0
Revert "Revert "Bump version to 1.5.0""
Had to do this to test the autoupdater.
[fix] [channel drop-down list] Show the stable channel in all cases.
Conflicts:
internal_packages/preferences/lib/tabs/update-channel-section.jsx
Fix broken autoupdater, for reals.
[master] Replace "Nylas N1" by "Nylas Mail" in build scripts
Summary: As discussed --- we need to make those changes to make the autoupdater work across versions.
Test Plan: Will run a build.
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3701
Revert "Revert "Revert "Bump version to 1.5.0"""
Need to set the version to 0.4.402 for testing purposes.
Set preferredChannel in the autoupdater instead of in the ChannelStore
It turns out that Squirrel checks for update at program launch. In some
cases, it would put Pro users on the "nylas-mail" channel because that's
the default channel if you don't pass a preferredChannel.
Conflicts:
src/flux/stores/update-channel-store.es6
Set the autoupdater preferredChannel to stable.
Don't try to move the app file to the Application folder ourselves
Because of MacOS Gatekeeper path randomization issues
(https://github.com/Squirrel/Squirrel.Mac/issues/182) we need the user
to move the app themselves. Changed the dialog to ask them to do this
politely.
Conflicts:
internal_packages/verify-install-location/lib/main.es6
Because of MacOS Gatekeeper path randomization issues
(https://github.com/Squirrel/Squirrel.Mac/issues/182) we need the user
to move the app themselves. Changed the dialog to ask them to do this
politely.
