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
