Summary: Adds inbox zero animations and empty states
Test Plan: Manual
Reviewers: bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2801
Summary: The emoji picker allows users to insert emoji to their messages on click. A few emoji that don't render properly in Chromium are replaced with PNGs, both in the composer view and the message list view, but only the Unicode characters are sent in the message bodies.
Test Plan: TODO
Reviewers: bengotow, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2787
- Closes popover on window resize:
- Re rendering popover on window resize will be a bit more tricky because
the FixedPopover only receives an origin rect. The one who
dispatches the action has the responsability of re dispatching when
the window resizes
- Fixes tiny behavior in send later popover
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:
Fix specs
Fix responding to mailto, files at launch
It's super important that `window:loaded` is /not/ sent from index.js because `loadSettings.bootstrapScript` is async and nothing is actually loaded yet. This was causing the app to dispatch the mailto:// links into the main window before a DraftStore existed.
I think this was necessary at one point because we had NylasWindows not using a bootstrapScript? Should not be here anymore...
Test Plan: Run a few new tests
Reviewers: juan, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2737
Summary: Shortens and simplifies UI variables so that unused variables are no longer present.
Test Plan: Tested locally.
Reviewers: evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2738
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: Themes can now be uninstalled by clicking a button in the theme picker, instead of going to `~/.nylas/packages` to delete the directory.
Test Plan: Tested locally.
Reviewers: evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2700
Summary:
Changes the delta code to handle new deltas on the Account object,
which are triggered by changes in sync state indicating various backend
issues. Saves the sync state in a new field on the Account object, which
is persisited in `config.cson`.
Includes several UI changes to display more information when an account has
backend sync issues. Adds better messages and new actions the user can take
based on the type of sync issue.
Additionally, fixes bug in action bridge that was preventing multi-arg global
actions from working.
Test Plan:
Manual, by testing different sync state values and triggering deltas from the
backend
Reviewers: juan, evan, bengotow
Reviewed By: evan, bengotow
Subscribers: khamidou
Differential Revision: https://phab.nylas.com/D2696
Summary: Adds a new visual theme picker to the menu that allows users to select different themes based on color palettes and then change their themes live.
Test Plan: Test included.
Reviewers: evan, bengotow
Reviewed By: evan, bengotow
Differential Revision: https://phab.nylas.com/D2669
Summary:
- Also refactors the code a bit for testability and maintainability
- Fixes#1515
Test Plan: - Unit tests
Reviewers: evan, drew, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2651
- 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
- Rather than have a `showing` prop on the fixed popover, I just remove it and put a span in it's place when it's gone. This means we always get componentDidMount when the popover appears and simplifies when to focus it's content.
- The fixed popover implements esc and blur behaviors itself
- The fixed popover uses the background-secondary color and works in dark mode
- The snooze items have hover and active states
Summary: The floating toolbar now takes an optional boolean to decide whether it shows the pointer.
Test Plan: Tested locally.
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2628
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
Also fix style issues with link text.
Fix cmd+k link editing when nothing is selected.
Make confirm button only appear when there are changes to be made
Summary:
This implements EditableList re-ordering via a new prop callback.
You can drag and drop items in the mail rules list and the accounts list.
Note that you can't drag between lists - right now this is just to enable
re-ordering.
Test Plan: No new specs yet
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2495
- Updates OutlineView to reuse OutlineViewItem for creating new items
- Adds ability to edit outline view items via double click or right
click
- Cleans up css and code and sidebar item
- Updates SyncbackCategoryTask to update categories as well
- Adds 405 to permanent api error codes
Summary: Send and Archive plus a new setting.
Test Plan: new tests
Reviewers: bengotow, juan
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2446
Summary:
This is a refactor of the toolbar in the contenteditable. Goals of this
are:
1. Allow developers to add new buttons to the toolbar
2. Allow developers to add other component types to the floating toolbar (like the LinkEditor)
3. Make the toolbar declaratively defined instead of imperatively set
4. Separate out logical units of the toolbar into individual sections
5. Clean up `innerState` of the Contenteditable
The Floating Toolbar used to be an imperative mess. Doing simple
functionality additions required re-understanding a very complex set of
logic to hide and show the toolbar and delecately manage focus states.
There also was no real capacity for any developer to extend the toolbar.
It also used to be completely outside of our `atomicEdit` system and was a
legacy of having raw access to contenteditable controls (since it all used
to be directly inside of the contenteditable)
Finally it was difficult to declaratively define things because the
`innerState` of the Contenteditable was inconsistently used and its
lifecycle not properly thought through. This fixed several lifecycle bugs
with that.
Along the way several of the DOMUtils methods were also subtly not
functional and fixed.
The Toolbar is now broken apart into separate logical units.
There are now `ContentedtiableExtension`s that declare what should be
displayed in the toolbar at any given moment.
They define a method called `toolbarComponentData`. This is a pure
function of the state of the `Contenteditable`. If selection and content
conditions look correct, then that method will return a component to
render. This is how we declaratively define whether a toolbar should be
visible or not instead of manually setting `hide` & `show` bits.
There is also a `toolbarButtons` method that declaratively defines buttons
that can go in the new `<ToolbarButtons>` component.
The `ToolbarButtonManager` takes care of extracting these and binding the
correct editorAPI context.
Now the `<LinkEditor>` is a separate component from the `<ToolbarButtons>`
instead of being smashed together.
The `LinkManager` takes care of declaring when the `LinkEditor` should be
displayed and has properly bound methods to update the `contenteditable`
through the standard `atomicEdit` interface.
If users have additional contenteditable popup plugins (like displaying
extra info on a name or some content in the composer), they can now
implement the `toolbarComponentData` api and declaratively define that
information based on the state of the contenteditable.
Test Plan: TODO
Reviewers: bengotow, juan
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2442
- Refactors some of the old code which was 💩
- Makes SidbarSection a factory for different types of items for the
OutlineView
- Decided not to create a OutlineViewItem.Model class since the only
purpose it would serve would be to validate getters for props or for
documentation, both of which are already done via React.PropTypes.
- Adds sections when looking at unified inbox and integrates with new
mailbox perspecitve interface
- Updates OutlineViewItem a bit + styles
- Tests missing
- Creates OutlineView generic component and uses that instead of custom
code
- Refactors AccountSidebarStore:
- Split the generation of the state tree into smaller functions
- Adds different types of account sidebar items and sections, which contain
logic and props necessary to be rendered as OutlineViewItems, and
removes that logic from the store
- Removes WorkspaceStore.SidebarItem and removes the ability to register
new sidebar items. If people want to add something to the sidebar they
can just register a Component via the component registry and use the
OutlineView component
- Removes the DraftListSidebarItem, which was basically duplicated code
for an item but with a different data source. This is now handled
generically by the account sidebar by rendering OutlineViewItems with
different props and handlers
- Clean ups here and there:
- TODO
- Add AccountSwitcher
- Revisit calculation and generation of the state tree. Should the
parent store contain and update the entire state all the time.
Should separate items inside the tree have their own data sources?
- This would avoid having the AccountSidebarStore listen to a bunch of
different other stores, and the specific logic wold be contained
inside each item type.