Mailspring/app/spec/stores/identity-store-spec.ts

109 lines
3.7 KiB
TypeScript
Raw Normal View History

import { Utils, KeyManager } from 'mailspring-exports';
Replace Babel with TypeScript compiler, switch entire app to TypeScript 🎉 (#1404) * Switch to using Typescript instead of Babel * Switch all es6 / jsx file extensions to ts / tsx * Convert Utils to a TS module from module.exports style module * Move everything from module.exports to typescript exports * Define .d.ts files for mailspring-exports and component kit… Yes it seems this is the best option :( * Load up on those @types * Synthesize TS types from PropTypes for standard components * Add types to Model classes and move constructor constants to instance vars * 9800 => 7700 TS errors * 7700 => 5600 TS errors * 5600 => 5330 TS errors * 5330 => 4866 TS errors * 4866 => 4426 TS errors * 4426 => 2411 TS errors * 2411 > 1598 TS errors * 1598 > 769 TS errors * 769 > 129 TS errors * 129 > 22 TS errors * Fix runtime errors * More runtime error fixes * Remove support for custom .es6 file extension * Remove a few odd remaining references to Nylas * Don’t ship Typescript support in the compiled app for now * Fix issues in compiled app - module resolution in TS is case sensitive? * README updates * Fix a few more TS errors * Make “No Signature” option clickable + selectable * Remove flicker when saving file and reloading keymaps * Fix mail rule item height in preferences * Fix missing spacing in thread sharing popover * Fix scrollbar ticks being nested incorrectly * Add Japanese as a manually reviewed language * Prevent the thread list from “sticking” * Re-use Sheet when switching root tabs, prevent sidebar from resetting * Ensure specs run * Update package configuration to avoid shpping types * Turn eslint back on - we will opt-in to the TS rules one by one
2019-03-05 03:03:12 +08:00
import { IdentityStore } from '../../src/flux/stores/identity-store';
2017-09-27 02:46:00 +08:00
import * as MailspringAPIRequest from '../../src/flux/mailspring-api-request';
feat(usage): Add a FeatureUsageStore and move Identity to the DB 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
2017-02-04 07:31:31 +08:00
2017-09-27 02:33:08 +08:00
const TEST_NYLAS_ID = 'icihsnqh4pwujyqihlrj70vh';
feat(usage): Add a FeatureUsageStore and move Identity to the DB 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
2017-02-04 07:31:31 +08:00
2017-09-27 02:33:08 +08:00
describe('IdentityStore', function identityStoreSpec() {
feat(usage): Add a FeatureUsageStore and move Identity to the DB 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
2017-02-04 07:31:31 +08:00
beforeEach(() => {
this.identityJSON = {
Replace Babel with TypeScript compiler, switch entire app to TypeScript 🎉 (#1404) * Switch to using Typescript instead of Babel * Switch all es6 / jsx file extensions to ts / tsx * Convert Utils to a TS module from module.exports style module * Move everything from module.exports to typescript exports * Define .d.ts files for mailspring-exports and component kit… Yes it seems this is the best option :( * Load up on those @types * Synthesize TS types from PropTypes for standard components * Add types to Model classes and move constructor constants to instance vars * 9800 => 7700 TS errors * 7700 => 5600 TS errors * 5600 => 5330 TS errors * 5330 => 4866 TS errors * 4866 => 4426 TS errors * 4426 => 2411 TS errors * 2411 > 1598 TS errors * 1598 > 769 TS errors * 769 > 129 TS errors * 129 > 22 TS errors * Fix runtime errors * More runtime error fixes * Remove support for custom .es6 file extension * Remove a few odd remaining references to Nylas * Don’t ship Typescript support in the compiled app for now * Fix issues in compiled app - module resolution in TS is case sensitive? * README updates * Fix a few more TS errors * Make “No Signature” option clickable + selectable * Remove flicker when saving file and reloading keymaps * Fix mail rule item height in preferences * Fix missing spacing in thread sharing popover * Fix scrollbar ticks being nested incorrectly * Add Japanese as a manually reviewed language * Prevent the thread list from “sticking” * Re-use Sheet when switching root tabs, prevent sidebar from resetting * Ensure specs run * Update package configuration to avoid shpping types * Turn eslint back on - we will opt-in to the TS rules one by one
2019-03-05 03:03:12 +08:00
firstName: 'Mailspring 050',
2017-09-27 02:33:08 +08:00
lastName: 'Test',
Replace Babel with TypeScript compiler, switch entire app to TypeScript 🎉 (#1404) * Switch to using Typescript instead of Babel * Switch all es6 / jsx file extensions to ts / tsx * Convert Utils to a TS module from module.exports style module * Move everything from module.exports to typescript exports * Define .d.ts files for mailspring-exports and component kit… Yes it seems this is the best option :( * Load up on those @types * Synthesize TS types from PropTypes for standard components * Add types to Model classes and move constructor constants to instance vars * 9800 => 7700 TS errors * 7700 => 5600 TS errors * 5600 => 5330 TS errors * 5330 => 4866 TS errors * 4866 => 4426 TS errors * 4426 => 2411 TS errors * 2411 > 1598 TS errors * 1598 > 769 TS errors * 769 > 129 TS errors * 129 > 22 TS errors * Fix runtime errors * More runtime error fixes * Remove support for custom .es6 file extension * Remove a few odd remaining references to Nylas * Don’t ship Typescript support in the compiled app for now * Fix issues in compiled app - module resolution in TS is case sensitive? * README updates * Fix a few more TS errors * Make “No Signature” option clickable + selectable * Remove flicker when saving file and reloading keymaps * Fix mail rule item height in preferences * Fix missing spacing in thread sharing popover * Fix scrollbar ticks being nested incorrectly * Add Japanese as a manually reviewed language * Prevent the thread list from “sticking” * Re-use Sheet when switching root tabs, prevent sidebar from resetting * Ensure specs run * Update package configuration to avoid shpping types * Turn eslint back on - we will opt-in to the TS rules one by one
2019-03-05 03:03:12 +08:00
email: 'mailspring050test@evanmorikawa.com',
feat(usage): Add a FeatureUsageStore and move Identity to the DB 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
2017-02-04 07:31:31 +08:00
id: TEST_NYLAS_ID,
featureUsage: {
feat: {
quota: 10,
usedInPeriod: 1,
},
},
2017-09-27 02:33:08 +08:00
token: 'secret token',
};
feat(usage): Add a FeatureUsageStore and move Identity to the DB 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
2017-02-04 07:31:31 +08:00
});
2017-09-27 02:33:08 +08:00
describe('saveIdentity', () => {
beforeEach(() => {
IdentityStore._identity = this.identityJSON;
2017-09-27 02:33:08 +08:00
spyOn(KeyManager, 'deletePassword');
spyOn(KeyManager, 'replacePassword');
spyOn(IdentityStore, 'trigger');
2017-09-27 02:36:58 +08:00
spyOn(AppEnv.config, 'set');
spyOn(AppEnv.config, 'unset');
});
2017-09-27 02:33:08 +08:00
it('clears passwords if unsetting', async () => {
await IdentityStore.saveIdentity(null);
2017-09-27 02:33:08 +08:00
expect(KeyManager.deletePassword).toHaveBeenCalled();
expect(KeyManager.replacePassword).not.toHaveBeenCalled();
2017-09-27 02:36:58 +08:00
expect(AppEnv.config.set).toHaveBeenCalled();
const ident = AppEnv.config.set.calls[0].args[1];
2017-09-27 02:33:08 +08:00
expect(ident).toBe(null);
});
2017-09-27 02:33:08 +08:00
it('applies changes synchronously', async () => {
2017-08-27 06:13:34 +08:00
const used = () => IdentityStore.identity().featureUsage.feat.usedInPeriod;
2017-09-27 02:33:08 +08:00
expect(used()).toBe(1);
2017-08-27 06:13:34 +08:00
const next = JSON.parse(JSON.stringify(this.identityJSON));
next.featureUsage.feat.usedInPeriod += 1;
await IdentityStore.saveIdentity(next);
2017-08-27 06:13:34 +08:00
expect(used()).toBe(2);
});
feat(usage): Add a FeatureUsageStore and move Identity to the DB 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
2017-02-04 07:31:31 +08:00
});
2017-09-27 02:33:08 +08:00
describe('returning the identity object', () => {
beforeEach(() => {
2017-09-27 02:33:08 +08:00
spyOn(IdentityStore, 'saveIdentity').andReturn(Promise.resolve());
});
2017-09-27 02:33:08 +08:00
it('returns the identity as null if it looks blank', () => {
feat(usage): Add a FeatureUsageStore and move Identity to the DB 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
2017-02-04 07:31:31 +08:00
IdentityStore._identity = null;
expect(IdentityStore.identity()).toBe(null);
IdentityStore._identity = {};
expect(IdentityStore.identity()).toBe(null);
2017-09-27 02:33:08 +08:00
IdentityStore._identity = { token: 'bad' };
feat(usage): Add a FeatureUsageStore and move Identity to the DB 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
2017-02-04 07:31:31 +08:00
expect(IdentityStore.identity()).toBe(null);
});
2017-09-27 02:33:08 +08:00
it('returns a proper clone of the identity', () => {
IdentityStore._identity = { id: 'bar', deep: { obj: 'baz' } };
feat(usage): Add a FeatureUsageStore and move Identity to the DB 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
2017-02-04 07:31:31 +08:00
const ident = IdentityStore.identity();
IdentityStore._identity.deep.obj = 'changed';
expect(ident.deep.obj).toBe('baz');
});
});
2017-09-27 02:33:08 +08:00
describe('fetchIdentity', () => {
beforeEach(() => {
IdentityStore._identity = this.identityJSON;
2017-09-27 02:33:08 +08:00
spyOn(IdentityStore, 'saveIdentity');
2017-09-27 02:36:58 +08:00
spyOn(AppEnv, 'reportError');
2017-09-27 02:33:08 +08:00
spyOn(console, 'error');
});
2017-09-27 02:33:08 +08:00
it('saves the identity returned', async () => {
const resp = Utils.deepClone(this.identityJSON);
2017-09-27 02:33:08 +08:00
resp.featureUsage.feat.quota = 5;
2017-09-27 02:46:00 +08:00
spyOn(MailspringAPIRequest, 'makeRequest').andCallFake(() => {
2017-09-27 02:33:08 +08:00
return Promise.resolve(resp);
});
await IdentityStore.fetchIdentity();
2017-09-27 02:46:00 +08:00
expect(MailspringAPIRequest.makeRequest).toHaveBeenCalled();
const options = MailspringAPIRequest.makeRequest.calls[0].args[0];
2017-09-27 02:33:08 +08:00
expect(options.path).toEqual('/api/me');
expect(IdentityStore.saveIdentity).toHaveBeenCalled();
const newIdent = IdentityStore.saveIdentity.calls[0].args[0];
expect(newIdent.featureUsage.feat.quota).toBe(5);
2017-09-27 02:36:58 +08:00
expect(AppEnv.reportError).not.toHaveBeenCalled();
});
2017-09-27 02:33:08 +08:00
it('errors if the json is invalid', async () => {
2017-09-27 02:46:00 +08:00
spyOn(MailspringAPIRequest, 'makeRequest').andCallFake(() => {
2017-09-27 02:33:08 +08:00
return Promise.resolve({});
});
await IdentityStore.fetchIdentity();
2017-09-27 02:36:58 +08:00
expect(AppEnv.reportError).toHaveBeenCalled();
2017-09-27 02:33:08 +08:00
expect(IdentityStore.saveIdentity).not.toHaveBeenCalled();
});
});
feat(usage): Add a FeatureUsageStore and move Identity to the DB 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
2017-02-04 07:31:31 +08:00
});