Foundry376/Mailspring
1
1
Fork 0
mirror of https://github.com/Foundry376/Mailspring.git synced 2024-09-22 16:26:08 +08:00
Code Issues Packages Projects Releases Wiki Activity
Mailspring/spec/tasks/destroy-category-task-spec.coffee

135 lines
4.4 KiB
CoffeeScript
Raw Normal View History

feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
{DestroyCategoryTask,
NylasAPI,
Task,
Fix specs for destroy and syncback category tasks
2016-01-23 06:52:19 +08:00
Category,
AccountStore,
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
APIError,
Unified inbox mailbox perspectives working (sidebar disabled atm)
2016-01-18 16:47:04 +08:00
Category,
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
DatabaseStore,
DatabaseTransaction} = require "nylas-exports"
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
describe "DestroyCategoryTask", ->
pathOf = (fn) ->
fn.calls[0].args[0].path
methodOf = (fn) ->
fn.calls[0].args[0].method
accountIdOf = (fn) ->
fn.calls[0].args[0].accountId
nameOf = (fn) ->
fn.calls[0].args[0].body.display_name
Fix specs for destroy and syncback category tasks
2016-01-23 06:52:19 +08:00
makeAccount = ({usesFolders, usesLabels} = {}) ->
spyOn(AccountStore, "accountForId").andReturn {
usesFolders: -> usesFolders
usesLabels: -> usesLabels
}
Unified inbox mailbox perspectives working (sidebar disabled atm)
2016-01-18 16:47:04 +08:00
makeTask = ->
category = new Category
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
displayName: "important emails"
accountId: "account 123"
serverId: "server-444"
new DestroyCategoryTask
category: category
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
beforeEach ->
refactor(folders): Make folders disappear when deleted rather than graying out until confirmed Summary: When testing we thought that Deleting a folder turns it grey but keeps it in the folder list; trying again throws this error. It turns out, that the folder was actually going to be deleted if left alone long enough, however, since it sat there grey for a while we would attempt to delete it again which would throw an error. To get around this, we removed the isDeleted grey state and unpersisted the folder right when delete is clicked then persisted the folder if there was an API error. fix(folders): Add new and extend destroy category task specs Test Plan: I tested locally, tweaked destroy category task specs and added minor new specs Reviewers: bengotow, juan Reviewed By: juan Subscribers: bengotow, juan Differential Revision: https://phab.nylas.com/D3131
2016-07-29 03:10:40 +08:00
spyOn(DatabaseTransaction.prototype, 'unpersistModel').andCallFake -> Promise.resolve()
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
spyOn(DatabaseTransaction.prototype, 'persistModel').andCallFake -> Promise.resolve()
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
describe "performLocal", ->
it "sets an `isDeleted` flag and persists the category", ->
Unified inbox mailbox perspectives working (sidebar disabled atm)
2016-01-18 16:47:04 +08:00
task = makeTask()
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
runs =>
task.performLocal()
waitsFor =>
refactor(folders): Make folders disappear when deleted rather than graying out until confirmed Summary: When testing we thought that Deleting a folder turns it grey but keeps it in the folder list; trying again throws this error. It turns out, that the folder was actually going to be deleted if left alone long enough, however, since it sat there grey for a while we would attempt to delete it again which would throw an error. To get around this, we removed the isDeleted grey state and unpersisted the folder right when delete is clicked then persisted the folder if there was an API error. fix(folders): Add new and extend destroy category task specs Test Plan: I tested locally, tweaked destroy category task specs and added minor new specs Reviewers: bengotow, juan Reviewed By: juan Subscribers: bengotow, juan Differential Revision: https://phab.nylas.com/D3131
2016-07-29 03:10:40 +08:00
DatabaseTransaction.prototype.unpersistModel.callCount > 0
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
runs =>
refactor(folders): Make folders disappear when deleted rather than graying out until confirmed Summary: When testing we thought that Deleting a folder turns it grey but keeps it in the folder list; trying again throws this error. It turns out, that the folder was actually going to be deleted if left alone long enough, however, since it sat there grey for a while we would attempt to delete it again which would throw an error. To get around this, we removed the isDeleted grey state and unpersisted the folder right when delete is clicked then persisted the folder if there was an API error. fix(folders): Add new and extend destroy category task specs Test Plan: I tested locally, tweaked destroy category task specs and added minor new specs Reviewers: bengotow, juan Reviewed By: juan Subscribers: bengotow, juan Differential Revision: https://phab.nylas.com/D3131
2016-07-29 03:10:40 +08:00
model = DatabaseTransaction.prototype.unpersistModel.calls[0].args[0]
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
expect(model.serverId).toEqual "server-444"
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
describe "performRemote", ->
it "throws error when no category present", ->
waitsForPromise ->
Unified inbox mailbox perspectives working (sidebar disabled atm)
2016-01-18 16:47:04 +08:00
task = makeTask()
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
task.category = null
task.performRemote()
.then ->
throw new Error('The promise should reject')
.catch Error, (err) ->
expect(err).toBeDefined()
it "throws error when category does not have a serverId", ->
waitsForPromise ->
Unified inbox mailbox perspectives working (sidebar disabled atm)
2016-01-18 16:47:04 +08:00
task = makeTask()
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
task.category.serverId = undefined
task.performRemote()
.then ->
throw new Error('The promise should reject')
.catch Error, (err) ->
expect(err).toBeDefined()
describe "when request succeeds", ->
beforeEach ->
spyOn(NylasAPI, "makeRequest").andCallFake -> Promise.resolve("null")
refactor(folders): Make folders disappear when deleted rather than graying out until confirmed Summary: When testing we thought that Deleting a folder turns it grey but keeps it in the folder list; trying again throws this error. It turns out, that the folder was actually going to be deleted if left alone long enough, however, since it sat there grey for a while we would attempt to delete it again which would throw an error. To get around this, we removed the isDeleted grey state and unpersisted the folder right when delete is clicked then persisted the folder if there was an API error. fix(folders): Add new and extend destroy category task specs Test Plan: I tested locally, tweaked destroy category task specs and added minor new specs Reviewers: bengotow, juan Reviewed By: juan Subscribers: bengotow, juan Differential Revision: https://phab.nylas.com/D3131
2016-07-29 03:10:40 +08:00
spyOn(NylasAPI, "incrementRemoteChangeLock")
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
refactor(folders): Make folders disappear when deleted rather than graying out until confirmed Summary: When testing we thought that Deleting a folder turns it grey but keeps it in the folder list; trying again throws this error. It turns out, that the folder was actually going to be deleted if left alone long enough, however, since it sat there grey for a while we would attempt to delete it again which would throw an error. To get around this, we removed the isDeleted grey state and unpersisted the folder right when delete is clicked then persisted the folder if there was an API error. fix(folders): Add new and extend destroy category task specs Test Plan: I tested locally, tweaked destroy category task specs and added minor new specs Reviewers: bengotow, juan Reviewed By: juan Subscribers: bengotow, juan Differential Revision: https://phab.nylas.com/D3131
2016-07-29 03:10:40 +08:00
it "blocks other remote changes to that category", ->
makeAccount()
task = makeTask()
task.performRemote()
expect(NylasAPI.incrementRemoteChangeLock).toHaveBeenCalled()
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
it "sends API req to /labels if user uses labels", ->
Fix specs for destroy and syncback category tasks
2016-01-23 06:52:19 +08:00
makeAccount(usesLabels: true)
Unified inbox mailbox perspectives working (sidebar disabled atm)
2016-01-18 16:47:04 +08:00
task = makeTask()
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
task.performRemote()
expect(pathOf(NylasAPI.makeRequest)).toBe "/labels/server-444"
it "sends API req to /folders if user uses folders", ->
Fix specs for destroy and syncback category tasks
2016-01-23 06:52:19 +08:00
makeAccount(usesFolders: true)
Unified inbox mailbox perspectives working (sidebar disabled atm)
2016-01-18 16:47:04 +08:00
task = makeTask()
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
task.performRemote()
expect(pathOf(NylasAPI.makeRequest)).toBe "/folders/server-444"
it "sends DELETE request", ->
Fix specs for destroy and syncback category tasks
2016-01-23 06:52:19 +08:00
makeAccount()
Unified inbox mailbox perspectives working (sidebar disabled atm)
2016-01-18 16:47:04 +08:00
task = makeTask()
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
task.performRemote()
expect(methodOf(NylasAPI.makeRequest)).toBe "DELETE"
it "sends the account id", ->
Fix specs for destroy and syncback category tasks
2016-01-23 06:52:19 +08:00
makeAccount()
Unified inbox mailbox perspectives working (sidebar disabled atm)
2016-01-18 16:47:04 +08:00
task = makeTask()
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
task.performRemote()
expect(accountIdOf(NylasAPI.makeRequest)).toBe "account 123"
describe "when request fails", ->
beforeEach ->
Fix specs for destroy and syncback category tasks
2016-01-23 06:52:19 +08:00
makeAccount()
refactor(folders): Make folders disappear when deleted rather than graying out until confirmed Summary: When testing we thought that Deleting a folder turns it grey but keeps it in the folder list; trying again throws this error. It turns out, that the folder was actually going to be deleted if left alone long enough, however, since it sat there grey for a while we would attempt to delete it again which would throw an error. To get around this, we removed the isDeleted grey state and unpersisted the folder right when delete is clicked then persisted the folder if there was an API error. fix(folders): Add new and extend destroy category task specs Test Plan: I tested locally, tweaked destroy category task specs and added minor new specs Reviewers: bengotow, juan Reviewed By: juan Subscribers: bengotow, juan Differential Revision: https://phab.nylas.com/D3131
2016-07-29 03:10:40 +08:00
spyOn(NylasAPI, 'decrementRemoteChangeLock')
feat(error): improve error reporting. Now `NylasEnv.reportError` Summary: The goal is to let us see what plugins are throwing errors on Sentry. We are using a Sentry `tag` to identify and group plugins and their errors. Along the way, I cleaned up the error catching and reporting system. There was a lot of duplicate error logic (that wasn't always right) and some legacy Atom error handling. Now, if you catch an error that we should report (like when handling extensions), call `NylasEnv.reportError`. This used to be called `emitError` but I changed it to `reportError` to be consistent with the ErrorReporter and be a bit more indicative of what it does. In the production version, the `ErrorLogger` will forward the request to the `nylas-private-error-reporter` which will report to Sentry. The `reportError` function also now inspects the stack to determine which plugin(s) it came from. These are passed along to Sentry. I also cleaned up the `console.log` and `console.error` code. We were logging errors multiple times making the console confusing to read. Worse is that we were logging the `error` object, which would print not the stack of the actual error, but rather the stack of where the console.error was logged from. Printing `error.stack` instead shows much more accurate stack traces. See changes in the Edgehill repo here: https://github.com/nylas/edgehill/commit/8c4a86eb7ee1a06249a9ae35397e2084a09ad1dc Test Plan: Manual Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2509
2016-02-04 07:06:52 +08:00
spyOn(NylasEnv, 'reportError')
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
spyOn(NylasAPI, 'makeRequest').andCallFake ->
Promise.reject(new APIError({statusCode: 403}))
refactor(folders): Make folders disappear when deleted rather than graying out until confirmed Summary: When testing we thought that Deleting a folder turns it grey but keeps it in the folder list; trying again throws this error. It turns out, that the folder was actually going to be deleted if left alone long enough, however, since it sat there grey for a while we would attempt to delete it again which would throw an error. To get around this, we removed the isDeleted grey state and unpersisted the folder right when delete is clicked then persisted the folder if there was an API error. fix(folders): Add new and extend destroy category task specs Test Plan: I tested locally, tweaked destroy category task specs and added minor new specs Reviewers: bengotow, juan Reviewed By: juan Subscribers: bengotow, juan Differential Revision: https://phab.nylas.com/D3131
2016-07-29 03:10:40 +08:00
it "persists the category and notifies error", ->
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
waitsForPromise ->
Unified inbox mailbox perspectives working (sidebar disabled atm)
2016-01-18 16:47:04 +08:00
task = makeTask()
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
spyOn(task, "_notifyUserOfError")
task.performRemote().then (status) ->
expect(status).toEqual Task.Status.Failed
expect(task._notifyUserOfError).toHaveBeenCalled()
feat(error): improve error reporting. Now `NylasEnv.reportError` Summary: The goal is to let us see what plugins are throwing errors on Sentry. We are using a Sentry `tag` to identify and group plugins and their errors. Along the way, I cleaned up the error catching and reporting system. There was a lot of duplicate error logic (that wasn't always right) and some legacy Atom error handling. Now, if you catch an error that we should report (like when handling extensions), call `NylasEnv.reportError`. This used to be called `emitError` but I changed it to `reportError` to be consistent with the ErrorReporter and be a bit more indicative of what it does. In the production version, the `ErrorLogger` will forward the request to the `nylas-private-error-reporter` which will report to Sentry. The `reportError` function also now inspects the stack to determine which plugin(s) it came from. These are passed along to Sentry. I also cleaned up the `console.log` and `console.error` code. We were logging errors multiple times making the console confusing to read. Worse is that we were logging the `error` object, which would print not the stack of the actual error, but rather the stack of where the console.error was logged from. Printing `error.stack` instead shows much more accurate stack traces. See changes in the Edgehill repo here: https://github.com/nylas/edgehill/commit/8c4a86eb7ee1a06249a9ae35397e2084a09ad1dc Test Plan: Manual Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2509
2016-02-04 07:06:52 +08:00
expect(NylasEnv.reportError).toHaveBeenCalled()
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
expect(DatabaseTransaction.prototype.persistModel).toHaveBeenCalled()
model = DatabaseTransaction.prototype.persistModel.calls[0].args[0]
feat(sidebar): Add sidebar controls to add and remove categories Summary: - Refactors account-sidebar internal package: - Separates into smaller react components - Makes DisclosureTriangle its own independent component - Adds data to AccountSidebarStore to allow removal or addition of items for a specific section of the sidebar - Adds button and input and css styles to create categories - Adds context menu to destroy a category - Adds new method to CategoryStore to get the icon name for the categories of the current account - Removes some unused code Test Plan: Manual Reviewers: evan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2283
2015-11-24 11:41:53 +08:00
expect(model.serverId).toEqual "server-444"
refactor(folders): Make folders disappear when deleted rather than graying out until confirmed Summary: When testing we thought that Deleting a folder turns it grey but keeps it in the folder list; trying again throws this error. It turns out, that the folder was actually going to be deleted if left alone long enough, however, since it sat there grey for a while we would attempt to delete it again which would throw an error. To get around this, we removed the isDeleted grey state and unpersisted the folder right when delete is clicked then persisted the folder if there was an API error. fix(folders): Add new and extend destroy category task specs Test Plan: I tested locally, tweaked destroy category task specs and added minor new specs Reviewers: bengotow, juan Reviewed By: juan Subscribers: bengotow, juan Differential Revision: https://phab.nylas.com/D3131
2016-07-29 03:10:40 +08:00
expect(NylasAPI.decrementRemoteChangeLock).toHaveBeenCalled
fix(delete-category): Resolve regression in error message (#1244)
2016-02-09 09:40:37 +08:00
describe "_notifyUserOfError", ->
it "should present an error dialog", ->
spyOn(NylasEnv, 'showErrorDialog')
task = makeTask()
es6(tasks): Convert all remaining tasks to ES6 Summary: after refactoring some things last week and spending time futsing with coffeescript, I’m pretty convinced it’s worth moving important parts of the app to ES6 to be able to use ESLint as part of our dev workflow Test Plan: Run existing tests, tested manually. Did not convert the tests in this diff, breaking one part at a time! Reviewers: evan, juan Reviewed By: juan Differential Revision: https://phab.nylas.com/D2768
2016-03-22 07:50:10 +08:00
task._notifyUserOfError(task.category)
fix(delete-category): Resolve regression in error message (#1244)
2016-02-09 09:40:37 +08:00
expect(NylasEnv.showErrorDialog).toHaveBeenCalled()
Reference in a new issue Copy permalink