2015-05-20 07:06:59 +08:00
|
|
|
_ = require 'underscore'
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
|
2015-07-16 23:54:20 +08:00
|
|
|
Label = require '../../src/flux/models/label'
|
2015-09-16 09:05:48 +08:00
|
|
|
Thread = require '../../src/flux/models/thread'
|
2015-06-26 22:42:41 +08:00
|
|
|
TestModel = require '../fixtures/db-test-model'
|
|
|
|
ModelQuery = require '../../src/flux/models/query'
|
|
|
|
DatabaseStore = require '../../src/flux/stores/database-store'
|
perf(thread-list): Tailored SQLite indexes, ListTabular / ScrollRegion optimizations galore
Summary:
Allow Database models to create indexes, but don't autocreate bad ones
fix minor bug in error-reporter
Fix index on message list to make thread list lookups use proper index
Developer bar ignores state changes unless it's open
DatabaseView now asks for metadata for a set of items rather than calling a function for every item. Promise.props was cute but we really needed to make a single database query for all message metadata.
New "in" matcher so you can say `thread_id IN (1,2,3)`
Add .scroll-region-content-inner which is larger than the viewport by 1 page size, and uses transform(0,0,0) trick
ScrollRegion exposes `onScrollEnd` so listTabular, et al don't need to re-implement it with more timers. Also removing requestAnimationFrame which was causing us to request scrollTop when it was not ready, and caching the values of...
...clientHeight/scrollHeight while scrolling is in-flight
Updating rendered content 10 rows at a time (RangeChunkSize) was a bad idea. Instead, add every row in a render: pass as it comes in (less work all the time vs more work intermittently). Also remove bad requestAnimationFrame, and prevent calls to...
...updateRangeState from triggering additional calls to updateRangeState by removing `componentDidUpdate => updateRangeState `
Turning off hover (pointer-events:none) is now standard in ScrollRegion
Loading text in the scroll tooltip, instead of random date shown
Handle query parse errors by catching error and throwing a better more explanatory error
Replace "quick action" retina images with background images to make React render easier
Replace hasTagId with a faster implementation which doesn't call functions and doesn't build a temporary array
Print query durations when printing to console instead of only in metadata
Remove headers from support from ListTabular, we'll never use it
Making columns part of state was a good idea but changing the array causes the entire ListTabular to re-render. To avoid this, be smarter about updating columns. This logic could potentially go in `componentDidReceiveProps` too.
Fix specs and add 6 more for new database store functionality
Test Plan: Run 6 new specs. More in the works?
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D1651
2015-06-18 11:12:48 +08:00
|
|
|
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
testMatchers = {'id': 'b'}
|
2015-08-29 02:12:53 +08:00
|
|
|
testModelInstance = new TestModel(id: "1234")
|
|
|
|
testModelInstanceA = new TestModel(id: "AAA")
|
|
|
|
testModelInstanceB = new TestModel(id: "BBB")
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
|
|
|
|
describe "DatabaseStore", ->
|
|
|
|
beforeEach ->
|
2015-06-26 22:42:41 +08:00
|
|
|
TestModel.configureBasic()
|
2015-11-26 04:17:00 +08:00
|
|
|
|
|
|
|
DatabaseStore._atomicallyQueue = undefined
|
|
|
|
DatabaseStore._mutationQueue = undefined
|
|
|
|
DatabaseStore._inTransaction = false
|
|
|
|
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
spyOn(ModelQuery.prototype, 'where').andCallThrough()
|
2015-12-18 03:46:05 +08:00
|
|
|
spyOn(DatabaseStore, 'accumulateAndTrigger').andCallFake -> Promise.resolve()
|
2015-06-26 22:42:41 +08:00
|
|
|
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
@performed = []
|
2015-07-31 09:09:20 +08:00
|
|
|
|
|
|
|
# Note: We spy on _query and test all of the convenience methods that sit above
|
|
|
|
# it. None of these tests evaluate whether _query works!
|
feat(tasks): add Create, Update, Destroy tasks plus spec & lint fixes
Summary:
1. **Generic CUD Tasks**: There is now a generic `CreateModelTask`,
`UpdateModelTask`, and `DestroyModelTask`. These can either be used as-is
or trivially overridden to easily update simple objects. Hopefully all of
the boilerplate rollback, error handling, and undo logic won't have to be
re-duplicated on every task. There are also tests for these tasks. We use
them to perform mutating actions on `Metadata` objects.
1. **Failing on Promise Rejects**: Turns out that if a Promise rejected
due to an error or `Promise.reject` we were ignoring it and letting tests
pass. Now, tests will Fail if any unhandled promise rejects. This
uncovered a variety of errors throughout the test suite that had to be
fixed. The most significant one was during the `theme-manager` tests when
all packages (and their stores with async DB requests) was loaded. Long
after the `theme-manager` specs finished, those DB requests were
(somtimes) silently failing.
1. **Globally stub `DatabaseStore._query`**: All tests shouldn't actually
make queries on the database. Furthremore, the `inTransaction` block
doesn't resolve at all unless `_query` is stubbed. Instead of manually
remembering to do this in every test that touches the DB, it's now mocked
in `spec_helper`. This broke a handful of tests that needed to be manually
fixed.
1. **ESLint Fixes**: Some minor fixes to the linter config to prevent
yelling about minor ES6 things and ensuring we have the correct parser.
Test Plan: new tests
Reviewers: bengotow, juan, drew
Differential Revision: https://phab.nylas.com/D2419
Remove cloudState and N1-Send-Later
2016-01-05 08:39:14 +08:00
|
|
|
jasmine.unspy(DatabaseStore, "_query")
|
2015-06-26 22:42:41 +08:00
|
|
|
spyOn(DatabaseStore, "_query").andCallFake (query, values=[], options={}) =>
|
|
|
|
@performed.push({query: query, values: values})
|
2015-07-31 09:09:20 +08:00
|
|
|
return Promise.resolve([])
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
|
|
|
|
describe "find", ->
|
|
|
|
it "should return a ModelQuery for retrieving a single item by Id", ->
|
|
|
|
q = DatabaseStore.find(TestModel, "4")
|
2015-03-26 03:41:48 +08:00
|
|
|
expect(q.sql()).toBe("SELECT `TestModel`.`data` FROM `TestModel` WHERE `TestModel`.`id` = '4' LIMIT 1")
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
|
|
|
|
describe "findBy", ->
|
|
|
|
it "should pass the provided predicates on to the ModelQuery", ->
|
|
|
|
matchers = {'id': 'b'}
|
|
|
|
DatabaseStore.findBy(TestModel, testMatchers)
|
|
|
|
expect(ModelQuery.prototype.where).toHaveBeenCalledWith(testMatchers)
|
|
|
|
|
|
|
|
it "should return a ModelQuery ready to be executed", ->
|
|
|
|
q = DatabaseStore.findBy(TestModel, testMatchers)
|
2015-03-26 03:41:48 +08:00
|
|
|
expect(q.sql()).toBe("SELECT `TestModel`.`data` FROM `TestModel` WHERE `TestModel`.`id` = 'b' LIMIT 1")
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
|
|
|
|
describe "findAll", ->
|
|
|
|
it "should pass the provided predicates on to the ModelQuery", ->
|
|
|
|
DatabaseStore.findAll(TestModel, testMatchers)
|
|
|
|
expect(ModelQuery.prototype.where).toHaveBeenCalledWith(testMatchers)
|
|
|
|
|
|
|
|
it "should return a ModelQuery ready to be executed", ->
|
|
|
|
q = DatabaseStore.findAll(TestModel, testMatchers)
|
2015-03-26 03:41:48 +08:00
|
|
|
expect(q.sql()).toBe("SELECT `TestModel`.`data` FROM `TestModel` WHERE `TestModel`.`id` = 'b' ")
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
|
2015-09-16 09:05:48 +08:00
|
|
|
describe "modelify", ->
|
|
|
|
beforeEach ->
|
|
|
|
@models = [
|
|
|
|
new Thread(clientId: 'local-A'),
|
|
|
|
new Thread(clientId: 'local-B'),
|
|
|
|
new Thread(clientId: 'local-C'),
|
|
|
|
new Thread(clientId: 'local-D', serverId: 'SERVER:D'),
|
|
|
|
new Thread(clientId: 'local-E', serverId: 'SERVER:E'),
|
|
|
|
new Thread(clientId: 'local-F', serverId: 'SERVER:F'),
|
|
|
|
new Thread(clientId: 'local-G', serverId: 'SERVER:G')
|
|
|
|
]
|
|
|
|
# Actually returns correct sets for queries, since matchers can evaluate
|
|
|
|
# themselves against models in memory
|
|
|
|
spyOn(DatabaseStore, 'run').andCallFake (query) =>
|
|
|
|
results = []
|
|
|
|
for model in @models
|
|
|
|
found = _.every query._matchers, (matcher) ->
|
|
|
|
matcher.evaluate(model)
|
|
|
|
results.push(model) if found
|
|
|
|
Promise.resolve(results)
|
|
|
|
|
|
|
|
describe "when given an array or input that is not an array", ->
|
|
|
|
it "resolves immediately with an empty array", ->
|
|
|
|
waitsForPromise =>
|
|
|
|
DatabaseStore.modelify(Thread, null).then (output) =>
|
|
|
|
expect(output).toEqual([])
|
|
|
|
|
|
|
|
describe "when given an array of mixed IDs, clientIDs, and models", ->
|
|
|
|
it "resolves with an array of models", ->
|
|
|
|
input = ['SERVER:F', 'local-B', 'local-C', 'SERVER:D', @models[6]]
|
|
|
|
expectedOutput = [@models[5], @models[1], @models[2], @models[3], @models[6]]
|
|
|
|
waitsForPromise =>
|
|
|
|
DatabaseStore.modelify(Thread, input).then (output) =>
|
|
|
|
expect(output).toEqual(expectedOutput)
|
|
|
|
|
|
|
|
describe "when the input is only IDs", ->
|
|
|
|
it "resolves with an array of models", ->
|
|
|
|
input = ['SERVER:D', 'SERVER:F', 'SERVER:G']
|
|
|
|
expectedOutput = [@models[3], @models[5], @models[6]]
|
|
|
|
waitsForPromise =>
|
|
|
|
DatabaseStore.modelify(Thread, input).then (output) =>
|
|
|
|
expect(output).toEqual(expectedOutput)
|
|
|
|
|
|
|
|
describe "when the input is only clientIDs", ->
|
|
|
|
it "resolves with an array of models", ->
|
|
|
|
input = ['local-A', 'local-B', 'local-C', 'local-D']
|
|
|
|
expectedOutput = [@models[0], @models[1], @models[2], @models[3]]
|
|
|
|
waitsForPromise =>
|
|
|
|
DatabaseStore.modelify(Thread, input).then (output) =>
|
|
|
|
expect(output).toEqual(expectedOutput)
|
|
|
|
|
|
|
|
describe "when the input is all models", ->
|
|
|
|
it "resolves with an array of models", ->
|
|
|
|
input = [@models[0], @models[1], @models[2], @models[3]]
|
|
|
|
expectedOutput = [@models[0], @models[1], @models[2], @models[3]]
|
|
|
|
waitsForPromise =>
|
|
|
|
DatabaseStore.modelify(Thread, input).then (output) =>
|
|
|
|
expect(output).toEqual(expectedOutput)
|
|
|
|
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
describe "count", ->
|
|
|
|
it "should pass the provided predicates on to the ModelQuery", ->
|
|
|
|
DatabaseStore.findAll(TestModel, testMatchers)
|
|
|
|
expect(ModelQuery.prototype.where).toHaveBeenCalledWith(testMatchers)
|
|
|
|
|
|
|
|
it "should return a ModelQuery configured for COUNT ready to be executed", ->
|
|
|
|
q = DatabaseStore.findAll(TestModel, testMatchers)
|
2015-03-26 03:41:48 +08:00
|
|
|
expect(q.sql()).toBe("SELECT `TestModel`.`data` FROM `TestModel` WHERE `TestModel`.`id` = 'b' ")
|
fix(drafts): Various improvements and fixes to drafts, draft state management
Summary:
This diff contains a few major changes:
1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario:
- View thread with draft, edit draft
- Move to another thread
- Move back to thread with draft
- Move to another thread. Notice that one or more messages from thread with draft are still there.
There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great.
2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here:
- In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI.
- Previously, when you added a contact to To/CC/BCC, this happened:
<input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates
Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state.
To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source!
This diff includes a few minor fixes as well:
1. Draft.state is gone—use Message.object = draft instead
2. String model attributes should never be null
3. Pre-send checks that can cancel draft send
4. Put the entire curl history and task queue into feedback reports
5. Cache localIds for extra speed
6. Move us up to latest React
Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
|
|
|
|
2015-12-18 03:46:05 +08:00
|
|
|
describe "inTransaction", ->
|
|
|
|
it "calls the provided function inside an exclusive transaction", ->
|
2015-09-16 08:27:52 +08:00
|
|
|
waitsForPromise =>
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( =>
|
2015-09-16 08:27:52 +08:00
|
|
|
DatabaseStore._query("TEST")
|
|
|
|
).then =>
|
|
|
|
expect(@performed.length).toBe 3
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[0].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-09-16 08:27:52 +08:00
|
|
|
expect(@performed[1].query).toBe "TEST"
|
|
|
|
expect(@performed[2].query).toBe "COMMIT"
|
|
|
|
|
2015-10-23 05:19:39 +08:00
|
|
|
it "preserves resolved values", ->
|
|
|
|
waitsForPromise =>
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( =>
|
2015-10-23 05:19:39 +08:00
|
|
|
DatabaseStore._query("TEST")
|
|
|
|
return Promise.resolve("myValue")
|
|
|
|
).then (myValue) =>
|
|
|
|
expect(myValue).toBe "myValue"
|
|
|
|
|
2015-12-18 03:46:05 +08:00
|
|
|
it "always fires a COMMIT, even if the body function fails", ->
|
2015-09-16 08:27:52 +08:00
|
|
|
waitsForPromise =>
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( =>
|
2015-09-16 08:27:52 +08:00
|
|
|
throw new Error("BOOO")
|
|
|
|
).catch =>
|
2015-10-23 05:19:39 +08:00
|
|
|
expect(@performed.length).toBe 2
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[0].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-10-23 05:19:39 +08:00
|
|
|
expect(@performed[1].query).toBe "COMMIT"
|
2015-09-16 08:27:52 +08:00
|
|
|
|
|
|
|
it "can be called multiple times and get queued", ->
|
|
|
|
waitsForPromise =>
|
|
|
|
Promise.all([
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( -> )
|
|
|
|
DatabaseStore.inTransaction( -> )
|
|
|
|
DatabaseStore.inTransaction( -> )
|
2015-09-16 08:27:52 +08:00
|
|
|
]).then =>
|
|
|
|
expect(@performed.length).toBe 6
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[0].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-09-16 08:27:52 +08:00
|
|
|
expect(@performed[1].query).toBe "COMMIT"
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[2].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-09-16 08:27:52 +08:00
|
|
|
expect(@performed[3].query).toBe "COMMIT"
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[4].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-09-16 08:27:52 +08:00
|
|
|
expect(@performed[5].query).toBe "COMMIT"
|
|
|
|
|
2015-10-23 05:19:39 +08:00
|
|
|
it "carries on if one of them fails, but still calls the COMMIT for the failed block", ->
|
|
|
|
caughtError = false
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( => DatabaseStore._query("ONE") )
|
|
|
|
DatabaseStore.inTransaction( => throw new Error("fail") ).catch ->
|
2015-10-23 05:19:39 +08:00
|
|
|
caughtError = true
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( => DatabaseStore._query("THREE") )
|
2015-10-23 05:19:39 +08:00
|
|
|
advanceClock(100)
|
|
|
|
expect(@performed.length).toBe 8
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[0].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-10-23 05:19:39 +08:00
|
|
|
expect(@performed[1].query).toBe "ONE"
|
|
|
|
expect(@performed[2].query).toBe "COMMIT"
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[3].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-10-23 05:19:39 +08:00
|
|
|
expect(@performed[4].query).toBe "COMMIT"
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[5].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-10-23 05:19:39 +08:00
|
|
|
expect(@performed[6].query).toBe "THREE"
|
|
|
|
expect(@performed[7].query).toBe "COMMIT"
|
|
|
|
expect(caughtError).toBe true
|
|
|
|
|
|
|
|
it "is actually running in series and blocks on never-finishing specs", ->
|
|
|
|
resolver = null
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( -> )
|
2015-10-23 05:19:39 +08:00
|
|
|
advanceClock(100)
|
|
|
|
expect(@performed.length).toBe 2
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[0].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-10-23 05:19:39 +08:00
|
|
|
expect(@performed[1].query).toBe "COMMIT"
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( -> new Promise (resolve, reject) -> resolver = resolve)
|
2015-10-23 05:19:39 +08:00
|
|
|
advanceClock(100)
|
|
|
|
blockedPromiseDone = false
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( -> ).then =>
|
2015-10-23 05:19:39 +08:00
|
|
|
blockedPromiseDone = true
|
|
|
|
advanceClock(100)
|
|
|
|
expect(@performed.length).toBe 3
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[2].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-10-23 05:19:39 +08:00
|
|
|
expect(blockedPromiseDone).toBe false
|
|
|
|
|
|
|
|
# Now that we've made our assertion about blocking, we need to clean up
|
|
|
|
# our test and actually resolve that blocked promise now, otherwise
|
|
|
|
# remaining tests won't run properly.
|
|
|
|
advanceClock(100)
|
|
|
|
resolver()
|
|
|
|
advanceClock(100)
|
|
|
|
expect(blockedPromiseDone).toBe true
|
|
|
|
advanceClock(100)
|
|
|
|
|
|
|
|
it "can be called multiple times and preserve return values", ->
|
|
|
|
waitsForPromise =>
|
|
|
|
v1 = null
|
|
|
|
v2 = null
|
|
|
|
v3 = null
|
|
|
|
Promise.all([
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( -> "a" ).then (val) -> v1 = val
|
|
|
|
DatabaseStore.inTransaction( -> "b" ).then (val) -> v2 = val
|
|
|
|
DatabaseStore.inTransaction( -> "c" ).then (val) -> v3 = val
|
2015-10-23 05:19:39 +08:00
|
|
|
]).then =>
|
|
|
|
expect(v1).toBe "a"
|
|
|
|
expect(v2).toBe "b"
|
|
|
|
expect(v3).toBe "c"
|
|
|
|
|
2015-09-16 08:27:52 +08:00
|
|
|
it "can be called multiple times and get queued", ->
|
|
|
|
waitsForPromise =>
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseStore.inTransaction( -> )
|
|
|
|
.then -> DatabaseStore.inTransaction( -> )
|
|
|
|
.then -> DatabaseStore.inTransaction( -> )
|
2015-09-16 08:27:52 +08:00
|
|
|
.then =>
|
|
|
|
expect(@performed.length).toBe 6
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[0].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-09-16 08:27:52 +08:00
|
|
|
expect(@performed[1].query).toBe "COMMIT"
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[2].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-09-16 08:27:52 +08:00
|
|
|
expect(@performed[3].query).toBe "COMMIT"
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(@performed[4].query).toBe "BEGIN IMMEDIATE TRANSACTION"
|
2015-09-16 08:27:52 +08:00
|
|
|
expect(@performed[5].query).toBe "COMMIT"
|