Commit Graph

11 Commits

Author SHA1 Message Date
Scott Nonnenberg 26884432a2 Update TypeScript, Prettier and typescript-eslint for new TypeScript 3.8 syntax 2020-11-23 14:45:44 -05:00
Evan Hahn 8bfaf598af Add license headers across the project 2020-11-04 13:03:13 -06:00
Chris Svenningsen 8a2c17f65f Apply new ESLint rules to legacy code 2020-09-09 17:34:57 -07:00
Scott Nonnenberg 55f4cd591c Improve safety number logic in group conversations 2020-06-10 14:39:45 -07:00
Scott Nonnenberg cd60bdd08a Move conversations to SQLCipher 2018-10-01 18:18:37 -07:00
Scott Nonnenberg 43a44793c5 Remove jshint - move everything over to eslint
Also removed all hints of previous linters
2018-07-17 15:54:32 -07:00
Daniel Gasienica 95321e5d3e Remove Vim mode lines 2018-04-30 16:53:34 -04:00
Daniel Gasienica 1dd87ad197 Format all source code using Prettier 2018-04-30 16:53:34 -04:00
Scott Nonnenberg d8ce198f55 Fetch conversations once, clean up ConversationController API (#1420)
* Fetch conversations once, clean up ConversationController API

Race conditions around re-fetching have caused some problems recently,
so this removes the need to re-fetch conversations. They are fetched
once or saved once, and that is it. All interaction goes through the
ConversationController, which is the central source of truth.

We have two rules for Conversations:

1. If a conversation is in the ConversationController it doesn't need
   to be fetched, but its initial fetch/save might be in progress. You
   can wait for that fetch/save with conversation.initialPromise.
2. If a conversation is not already in the ConversationController, it's
   not yet in the database. It needs to be added to the
   ConversationController and saved to the database.

FREEBIE

* Remove Conversation.fetch() call in Message.handleDataMessage()

FREEBIE

* ConversationController.API cleanup: Fix two missing spots

FREEBIE
2017-09-01 09:10:41 -07:00
Scott Nonnenberg 3e0fa995dd When finding all groups involving a number, load from DB not memory
FREEBIE
2017-08-04 12:03:25 -07:00
lilia aed5735620 Improve keychange notice reliability/perf
Bind a single listener to keychange events from the storage interface,
which then looks up relevant conversations and adds notices to them,
with tests.

Previously we would need to instantiate a conversation model in order to
start listening to its key change events. In practice this usually
happens at startup but we shouldn't rely on it, and it incurs higher
overhead since it creates a different listener for each conversation.

// FREEBIE
2017-05-09 15:41:41 -07:00