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/internal_packages/message-list/lib/main.cjsx

30 lines
1 KiB
Plaintext
Raw Normal View History

feat(message-list): nav buttons disable if first or last message Summary: fix message list nav buttons fix buttons Test Plan: edgehill --test Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://review.inboxapp.com/D1332
2015-03-24 22:41:00 +08:00
{ComponentRegistry,
update(extensions): Rename DraftStoreExtension and MessageStoreExtension Summary: - Rename DraftStoreExtension to ComposerExtension - Rename MessageStoreExtension to MessageViewExtension - Rename ContenteditablePlugin to ContenteditableExtension - Update Contenteditable to use new naming convention - Adds support for extension handlers as props - Add ExtensionRegistry to register extensions: - ContenteditableExtensions will not be registered through the ExtensionRegistry. They are meant for internal use, or if anyone wants to use our Contenteditable component directly in their plugins. - Adds specs - Refactors internal_packages and src to use new names and new ExtensionRegistry api - Adds deprecation util function and deprecation notices for old api methods: - DraftStore.{registerExtension, unregisterExtension} - MessageStore.{registerExtension, unregisterExtension} - DraftStoreExtension.{onMouseUp, onTabDown} - MessageStoreExtension - Adds and updates docs Test Plan: - Unit tests Reviewers: bengotow, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2293
2015-11-28 03:49:24 +08:00
ExtensionRegistry,
fix(naming): Move atom/inbox/nilas refs to Nylas Conflicts: internal_packages/inbox-activity-bar/lib/activity-bar-long-poll-item.cjsx
2015-05-15 08:08:30 +08:00
WorkspaceStore} = require 'nylas-exports'
fix(message-sidebar): New ContactCard injectable role, updated FocusedContactStore - The FocusedContactStore was triggering too often, and leaving it up to the FullcontactStore to fetch the full Contact model for the focused contact (pulled from thread.) The FocusedContactStore triggers more responsibly, and registering for the role "MessageListSidebar:ContactCard" now gives you the focused contact as a full database model. The whole ContactCard region also fades in and out.
2015-09-25 09:58:53 +08:00
Add thread-sharing plugin Summary: Add thread-sharing plugin: - Add popover to enable sharing - Register custom nylas:// protocol to open a thread via protocol is thread exists Test Plan: Manual Reviewers: jackie, bengotow Reviewed By: jackie, bengotow Subscribers: jackie, halla Differential Revision: https://phab.nylas.com/D3265
2016-09-14 15:03:59 +08:00
MessageList = require("./message-list")
feat(babel6): Convert to use new es6 require syntax
2016-05-04 07:42:28 +08:00
MessageListHiddenMessagesToggle = require('./message-list-hidden-messages-toggle').default
feat(selection): Add new display for selection count + update toolbar Summary: - New behavior is that the in split mode, you will perform actions on the selection via the MessageListToolbar (the toolbar positioned above the message list) - Refactored and moved around a bunch of code to achieve this: - Mostly renaming stuff and moving stuff around and removing some duplication - Update naming of toolbar role to a single role, and update relevant code - Converted and refactored a bunch of code into ES6, specifically to reuse the code for the ThreadActionsToolbar at the 2 locations - Deprecated MultiselectActionBar in favor of MultiselectToolbar - Deprecated old roles - Punted the animation for the stackable cards in the selection display for now. - #370 Test Plan: - Manual and unit tests Reviewers: evan, drew, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2756
2016-03-18 00:50:30 +08:00
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
SidebarPluginContainer = require "./sidebar-plugin-container"
feat(babel6): Convert to use new es6 require syntax
2016-05-04 07:42:28 +08:00
SidebarParticipantPicker = require('./sidebar-participant-picker').default
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
module.exports =
feat(selection): Add new display for selection count + update toolbar Summary: - New behavior is that the in split mode, you will perform actions on the selection via the MessageListToolbar (the toolbar positioned above the message list) - Refactored and moved around a bunch of code to achieve this: - Mostly renaming stuff and moving stuff around and removing some duplication - Update naming of toolbar role to a single role, and update relevant code - Converted and refactored a bunch of code into ES6, specifically to reuse the code for the ThreadActionsToolbar at the 2 locations - Deprecated MultiselectActionBar in favor of MultiselectToolbar - Deprecated old roles - Punted the animation for the stackable cards in the selection display for now. - #370 Test Plan: - Manual and unit tests Reviewers: evan, drew, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2756
2016-03-18 00:50:30 +08:00
activate: ->
feat(drafts) Reply to draft and minor fixes Summary: Initial hooks for reply to message Per-message actions and reply to message! Always commit changes before openinig popout composer Flip message display - newest at bottom like Gmail WIP specs New activity bar inspector for deltas Don't allow long polling connection to restart after end() called A bit of activity bar refactoring and filter options, clear Include "On ... someone wrote" in replies / fw Slightly more robust quoted text removal, detects "On..." Abort request to really end it Additional specs for draft store Test Plan: Run 20 new tests! Reviewers: evan Reviewed By: evan Differential Revision: https://review.inboxapp.com/D1230
2015-02-25 08:19:47 +08:00
# Register Message List Actions we provide globally
feat(unsafe-components): Wrap injected components, catch exceptions, clean up ComponentRegistry Summary: This diff gives the ComponentRegistry a cleaner, smaller API. Instead of querying by name, location or role, it's now just location and role, and you can register components for one or more location and one or more roles without assigning the entries in the registry separate names. When you register with the ComponentRegistry, the syntax is also cleaner and uses the component's displayName instead of requiring you to provide a name. You also provide the actual component when unregistering, ensuring that you can't unregister someone else's component. InjectedComponent and InjectedComponentSet now wrap their children in UnsafeComponent, which prevents render/component lifecycle problems from propogating. Existing components have been updated: 1. maxWidth / minWidth are now containerStyles.maxWidth/minWidth 2. displayName is now required to use the CR. 3. containerRequired = false can be provided to exempt a component from being wrapped in an UnsafeComponent. This is useful because it's slightly faster and keeps DOM flat. This diff also makes the "Show Component Regions" more awesome. It displays column regions, since they now use the InjectedComponentSet, and also shows for InjectedComponent as well as InjectedComponentSet. Change ComponentRegistry syntax, lots more work on safely wrapping items. See description. Fix for inline flexbox scenarios (message actions) Allow ~/.inbox/packages to be symlinked to a github repo Test Plan: Run tests! Reviewers: evan Reviewed By: evan Differential Revision: https://review.inboxapp.com/D1457
2015-05-01 07:10:15 +08:00
ComponentRegistry.register MessageList,
refactor(layout): More configuration into WorkspaceStore, less in packages
2015-03-21 05:52:10 +08:00
location: WorkspaceStore.Location.MessageList
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
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
ComponentRegistry.register SidebarParticipantPicker,
fix(message-sidebar): New ContactCard injectable role, updated FocusedContactStore - The FocusedContactStore was triggering too often, and leaving it up to the FullcontactStore to fetch the full Contact model for the focused contact (pulled from thread.) The FocusedContactStore triggers more responsibly, and registering for the role "MessageListSidebar:ContactCard" now gives you the focused contact as a full database model. The whole ContactCard region also fades in and out.
2015-09-25 09:58:53 +08:00
location: WorkspaceStore.Location.MessageListSidebar
feat(selection): Add new display for selection count + update toolbar Summary: - New behavior is that the in split mode, you will perform actions on the selection via the MessageListToolbar (the toolbar positioned above the message list) - Refactored and moved around a bunch of code to achieve this: - Mostly renaming stuff and moving stuff around and removing some duplication - Update naming of toolbar role to a single role, and update relevant code - Converted and refactored a bunch of code into ES6, specifically to reuse the code for the ThreadActionsToolbar at the 2 locations - Deprecated MultiselectActionBar in favor of MultiselectToolbar - Deprecated old roles - Punted the animation for the stackable cards in the selection display for now. - #370 Test Plan: - Manual and unit tests Reviewers: evan, drew, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2756
2016-03-18 00:50:30 +08:00
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
ComponentRegistry.register SidebarPluginContainer,
feat(sidebar): add more Salesforce states Summary: add more Salesforce states more salesforce sidebar extract focused contacts into its own store fullcontact store fixes extract thread participants to own module typo Test Plan: edgehill --test Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://review.inboxapp.com/D1326
2015-03-21 07:31:35 +08:00
location: WorkspaceStore.Location.MessageListSidebar
feat(mode-switch): New layout designed for small form factors Summary: feat(mode-switch): almost working Remove SheetStore in favor of bigger WorkspaceStore Back button for mode switching Test Plan: Tests WIP Reviewers: evan Reviewed By: evan Differential Revision: https://review.inboxapp.com/D1292
2015-03-14 04:11:24 +08:00
feat(hidden-messages): Filter trash/spam messages. Fixes #1135 Summary: By default, the messages in a thread are now filtered to exclude ones moved to trash or spam. You can choose to view those messages by clicking the new bar in the message list. When you view your spam or trash, we only show the messages on those threads that have been marked as spam/trash. Test Plan: Run a couple new tests Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2662
2016-03-03 02:05:17 +08:00
ComponentRegistry.register MessageListHiddenMessagesToggle,
role: 'MessageListHeaders'
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
deactivate: ->
feat(unsafe-components): Wrap injected components, catch exceptions, clean up ComponentRegistry Summary: This diff gives the ComponentRegistry a cleaner, smaller API. Instead of querying by name, location or role, it's now just location and role, and you can register components for one or more location and one or more roles without assigning the entries in the registry separate names. When you register with the ComponentRegistry, the syntax is also cleaner and uses the component's displayName instead of requiring you to provide a name. You also provide the actual component when unregistering, ensuring that you can't unregister someone else's component. InjectedComponent and InjectedComponentSet now wrap their children in UnsafeComponent, which prevents render/component lifecycle problems from propogating. Existing components have been updated: 1. maxWidth / minWidth are now containerStyles.maxWidth/minWidth 2. displayName is now required to use the CR. 3. containerRequired = false can be provided to exempt a component from being wrapped in an UnsafeComponent. This is useful because it's slightly faster and keeps DOM flat. This diff also makes the "Show Component Regions" more awesome. It displays column regions, since they now use the InjectedComponentSet, and also shows for InjectedComponent as well as InjectedComponentSet. Change ComponentRegistry syntax, lots more work on safely wrapping items. See description. Fix for inline flexbox scenarios (message actions) Allow ~/.inbox/packages to be symlinked to a github repo Test Plan: Run tests! Reviewers: evan Reviewed By: evan Differential Revision: https://review.inboxapp.com/D1457
2015-05-01 07:10:15 +08:00
ComponentRegistry.unregister MessageList
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
ComponentRegistry.unregister SidebarPluginContainer
ComponentRegistry.unregister SidebarParticipantPicker
Reference in a new issue Copy permalink