Commit graph

9 commits

Author SHA1 Message Date
Juan Tejada f12896d54f fix(gmail-labels): Constraint so threads always belong to all,spam or trash
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
2016-03-10 14:13:31 -08:00
Juan Tejada 0d15c6cea6 fix(remove-from-view): Fix logic for delete/remove-from-view behavior:
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
2016-03-07 18:16:37 -08:00
Ben Gotow f63b7e66e4 feat(swipe-to-*): Gesture support and animation in thread list
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
2016-02-19 18:22:28 -08:00
Ben Gotow 8f7f63af3a TaskFactory now returns N tasks for performing standard actions, undo uses arrays 2016-01-21 13:46:04 -08:00
Ben Gotow 8957c560f5 More renaming of view => data source 2016-01-14 15:04:17 -08:00
Ben Gotow 14d6cec669 Rename MailViewFilter => MailboxPerspective 2016-01-08 14:58:31 -08:00
Ben Gotow a855a67d1d fix(message-list): Clicking Archive or Trash should pop back to the thread list 2015-10-23 15:21:37 -07:00
Evan Morikawa 6c0370d7a8 feat(tooltip): use native tooltip style 2015-10-21 11:27:57 -07:00
Ben Gotow e09d3e3e75 feat(trash): Trash for Gmail, and architectural changes for common tasks
Summary:
This diff centralizes logic for creating common tasks for things like moving to trash, archive, etc. TaskFactory exposes a set of convenience methods and hides the whole "and also remove the current label" business from the user.

This diff also formally separates the concept of "moving to trash" and "archiving" so that "remove" isn't used in an unclear way.

I also refactored where selection is managed. Previously you'd fire some action like archiveSelection and it'd clear the selection, but if you selected some items and used another method to archive a few, they were still selected. The selection is now bound to the ModelView as intended, so if items are removed from the modelView, they are removed from it's attached selection. This means that it shouldn't /technically/ be possible to have selected items which are not in view.

I haven't refactored the tests yet. They are likely broken...

Fix next/prev logic

Test Plan: Run tests

Reviewers: evan

Reviewed By: evan

Differential Revision: https://phab.nylas.com/D2157
2015-10-21 10:38:00 -07:00