Summary:
Refactored signature preferences page to allow more signatures than the previous 1-1 mapping for signatures and accounts. Created a multi select dropdown of the accounts for which a certain signature is set as default for. Added a button into the draft header From field to toggle between saved signatures.
refactor(signatures): Add basic add/remove capabilities to static
refactor(signatures): Hooked up signature actions and signature store for basic functionality
fix(signatures): Cleaned up signature store and started on multiselectdropdown
fix(signatures): Add multi signature toggle select to multiselect dropdown
build(signatures): Built framework for multiselect dropdown
build(signatures): Toggle button functionality for dropdown
build(signatures): Build multi select from components and add debounce
refactor(signatures): Move signature actions and signature store into flux
fix(signatures): Styled composer signatures button/dropdown and fixed preferences checkmarks
build(signatures): Finish main functionality, about to refactor composer signature button into injected component
fix(signatures): Changed position styles
fix(signatures): Fixed background color for dropdown button when blurred
build(signatures): Began to write tests for signatures store, preferences and dropdown
Test Plan: Wrote tests for preferences signatures, signature store, signature composer dropdown and refactored tests for signature composer extension. For signature composer extension I removed applyTransformsToDraft and unapplyTransformsToDraft and tested by sending emails with signatures to different providers to make sure the <signature> tag caused problems.
Reviewers: bengotow, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3073
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
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 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
Summary:
Add signatures back in.
Extract contenteditable css to its own file instead of being bundled with
the composer.
Test Plan: manual
Reviewers: juan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2295
