Summary:
- Removes controlled focus in the composer!
- No React components ever perfom focus in lifecycle methods. Never again.
- A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus"
- The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus.
- The MessageList never focuses anything automatically.
- Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView
- ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon.
- Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing.
- Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want.
- Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature.
Todos:
- Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur.
- Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable.
- Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon.
Test Plan: Broken
Reviewers: juan, evan
Reviewed By: juan, evan
Differential Revision: https://phab.nylas.com/D2814
Summary:
This diff implements a behavior change described in https://github.com/nylas/N1/issues/1722.
Reply buttons should prefer to focus an existing draft in reply to the same message, if one is pristine, altering it as necessary to switch between reply / reply-all. If no pristine reply is already there, it creates one.
Reply keyboard shortcuts should do the same, but more strictly - the shortcuts should switch between reply / reply-all for an existing draft regardless of whether it's pristine.
This diff also cleans up the DraftStore and moves all the draft creation itself to a new DraftFactory object. This makes it much easier to see what's going on in the DraftStore, and I also refactored away the "newMessageWithContext" method, which was breaking the logic for Reply vs Forward between a bunch of different helper methods and was hard to follow.
Test Plan: They're all wrecked. Will fix after concept is greenlighted
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2776
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
Summary:
This diff replaces "finalizeSessionBeforeSending" with a
plugin hook that is bidirectional and allows us to put the draft in
the "ready to send" state every time we save it, and restore it to
the "ready to edit" state every time a draft session is created to
edit it.
This diff also significantly restructures the draft tasks:
1. SyncbackDraftUploadsTask:
- ensures that `uploads` are converted to `files` and that any
existing files on the draft are part of the correct account.
1. SyncbackDraftTask:
- saves the draft, nothing else.
3. SendDraftTask
- sends the draft, nothing else.
- deletes the entire uploads directory for the draft
Test Plan: WIP
Reviewers: juan, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2753
Summary:
- In Gmail all threads /must/ belong to either All Mail, Trash and Spam, and
they are mutually exclusive, so we need to make sure that any add/remove
label operation still guarantees that constraint
- Update ChangeLabelsTask to modify the set of labels to add and remove
based on this rule
- Update tasksFor archiving, moving to trash and moving to spam so they
don't affect any other labels in the thread, as gmail does.
- Removing from view /will/ remove any current labels, but will also
move between all mail and trash as needed
- Remove Inbox, Trash and Spam from the CategoryPicker, as Gmail does
Test Plan: - Unit tests
Reviewers: drew, evan, bengotow
Reviewed By: drew, evan, bengotow
Differential Revision: https://phab.nylas.com/D2715
Summary:
- FixedPopover now correctly adjusts itself when overflowing outside
window, in all directions
- Updates styles
- Adds specs
- Remove Popover and popover.less, and refactor all code that used it in
favor of the new FixedPopover
Test Plan: Unit tests
Reviewers: drew, evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2697
Summary:
- Separate gmail's remove-from-view and delete behaviors and write logic
for each of those
- Remove MailboxPerspective::{canArchiveThreads, canTrashThreads,
removeThreads} and some unecessary code in TaskFactory
- Instead, add MailboxPerspective::tasksForRemovingFromPerspective (I
know its a bit of a mouthful)
- I initially tried to put all of the logic for each execution path
inside the TaskFactory by checking perspective types, but it made
more sense to use the polymorphism already in place for the different
perspective types.
- There is a default delete/remove-from-view behavior which is
configurable via simple ruleset objects. The gmail behavior is
configured in this way.
- Update swipe css classes based on destination of threads
- Fixes#1460:
- Update logic to display archive/trash buttons and context menu options correctly
when selected threads can be archived/trashed (not based on
perspective)
- Same for swiping
- Add a bunch of specs
- Convert some code to ES6
- TODO write some docs for new functions
Test Plan: Unit tests
Reviewers: drew, evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2682
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
- Adds a new InjectedComponentSet for the role 'ThreadList:Label'.
- Adds a new label to the thread list indicating the snooze date if the
thread has been snoozed
- Coerces MailLabel to achieve this. This is a temporary hack, we should
design a better view to display snooze date information
Summary:
- Add FixedPopover, an absolutely positioned popover component to use for swipe snoozing:
- This component needs to be finished, as its current behavior is primarily for the snooze plugin
- Updates popover.cjsx to properly render pointer for thesnooze popover for the `down` direction
- Adds new design assets
- Adds date input to snooze popover
Test Plan: - TODO
Reviewers: evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2624
Summary:
This diff does two things:
- It adds a new SwipeContainer that makes it easy to implement swipe gestures. This is built into listTabular, so you can create a list and define onSwipeLeft/Right to enable gestures.
- It adds support for basic add/remove animations to the thread list. This works by adding a CSS transition to `top` and also leaving removed rows around for a specified time. (these times need to match.) Pretty much just cloned the core idea from TimeoutTransitionGroup.
Test Plan: No tests yet
Reviewers: evan, juan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2581
Summary:
Adds a right click menu to the thread list
Moving to folders and labels #TODO
Test Plan: TODO
Reviewers: bengotow, juan
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2609
Summary:
- Add initial version of snooze and send later plugins
- Tests are missing since this will probably heavily change before we are done with them
Test Plan: - TODO
Reviewers: drew, bengotow, evan
Reviewed By: bengotow, evan
Differential Revision: https://phab.nylas.com/D2578
Summary:
This diff adds an "OutboxStore" which reflects the TaskQueue and
adds a progress bar / cancel button to drafts which are currently sending.
- Sending state is different from things like Send later because drafts
which are sending shouldn't be editable. You should have to stop them
from sending before editing. I think we can implement "Send Later"
indicators, etc. with a simple InjectedComponentSet on the draft list
rows, but the OutboxStore is woven into the DraftList query subscription
so every draft has a `uploadTaskId`.
- The TaskQueue now saves periodically (every one second) when there are
"Processing" tasks. This is not really necessary, but makes it super
easy for tasks to expose "progress", because they're essentially
serialized and propagated to all windows every one second with the
current progress value. Kind of questionable, but super convenient.
- I also cleaned up ListTabular and MultiselectList a bit because they
applied the className prop to an inner element and not the top one.
- If a DestroyDraft task is created for a draft without a server id, it
ends with Task.Status.Continue and not Failed.
- The SendDraftTask doesn't delete uploads until the send actually goes
through, in case the app crashes and it forgets the file IDs it created.
Test Plan: Tests coming soon
Reviewers: juan, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2524
