- Add uploads field to Message and removes cache from FileUploadsStore
- Updates draft via session from DraftStore
- This makes everything way cleaner
- This fixes bug when creating draft with uploads and the opening it in
new window
- Updates specs
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
Summary:
1. **Generic CUD Tasks**: There is now a generic `CreateModelTask`,
`UpdateModelTask`, and `DestroyModelTask`. These can either be used as-is
or trivially overridden to easily update simple objects. Hopefully all of
the boilerplate rollback, error handling, and undo logic won't have to be
re-duplicated on every task. There are also tests for these tasks. We use
them to perform mutating actions on `Metadata` objects.
1. **Failing on Promise Rejects**: Turns out that if a Promise rejected
due to an error or `Promise.reject` we were ignoring it and letting tests
pass. Now, tests will Fail if any unhandled promise rejects. This
uncovered a variety of errors throughout the test suite that had to be
fixed. The most significant one was during the `theme-manager` tests when
all packages (and their stores with async DB requests) was loaded. Long
after the `theme-manager` specs finished, those DB requests were
(somtimes) silently failing.
1. **Globally stub `DatabaseStore._query`**: All tests shouldn't actually
make queries on the database. Furthremore, the `inTransaction` block
doesn't resolve at all unless `_query` is stubbed. Instead of manually
remembering to do this in every test that touches the DB, it's now mocked
in `spec_helper`. This broke a handful of tests that needed to be manually
fixed.
1. **ESLint Fixes**: Some minor fixes to the linter config to prevent
yelling about minor ES6 things and ensuring we have the correct parser.
Test Plan: new tests
Reviewers: bengotow, juan, drew
Differential Revision: https://phab.nylas.com/D2419
Remove cloudState and N1-Send-Later
clicking outside:
- When focusing the composer via click inside the contenteditable region or via
tabbing, last text node before the signature (or blockquotes) will be focused.
- When focusing composer by clicking outside contenteditable region, it
will default to default contenteditable focus behavior via new method:
`nativeFocus`
Summary:
- WIP: Need to fix tests and some errors!
- Refactors Category class to hold information about its type
- Refactors CategoryStore to rely on observables instead of local caches
- Adds and updates Observables and helpers
- Refactors ContactStore to hold entire cache of contacts instead of per
current account
- Same for ContactRankingStore and other stores
- Refactors method names for AccountStore + some helpers
- Updates MailViewFilter to hold an account
- Adds basic Unified filter
- Replaces AccountStore.current calls with either:
- The account of the currently focused MailViewFilter
- The account associated with a thread, message, file, etc...
- A parameter to be passed in
- Arbitrarily, the first account in the AccountsStore
Test Plan: - Unit tests
Reviewers: evan, bengotow
Differential Revision: https://phab.nylas.com/D2423
Summary: When focusing the composer, select the end of the last text block above any signatures / quoted text (which can be visible by default in Fwd:).
Test Plan: Run tests
Reviewers: juan, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2411
Summary:
Remove FocusTrackingRegion—all CommandRegions should be focusable, and nesting the two creates varying behavior based on which is the parent
Calling focus() on an injected / unsafe component should always do /something/. Try the inner React method, inner DOM method, or call on ourselves
Rename contentEditable._focusEditor to "focus" since it intends to replace default focus behavior
In ComposerView, always change focus via setState, never by calling focus() directly. Rather than tracking `_lastFocusedField`, just focus whenever the activeElement isnt within the focusedField. Make body initial focus when draft is pristine...
...(ensures new drafts are focused)
Test Plan: Run tests
Reviewers: evan, juan
Reviewed By: evan, juan
Differential Revision: https://phab.nylas.com/D2406
Summary:
WIP:
This is a quick patch for Drew to make extensions async
We'll need to think through the upgrade/deprecation plan to roll out async
extensions across all of our APIs.
Test Plan: TODO
Reviewers: drew, evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2392
Summary:
- Rewrites composer extension adpater to support all versions of the
ComposerExtension API we've ever declared. This will allow old plugins (or
plugins that haven't been reinstalled after update) to keep functioning
without breaking N1
- Adds specs
Test Plan: - Unit tests
Reviewers: evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2399
Summary:
- Fixes bug with Composer focus caused by injected component. The composer body
was being focused, but the cursor remained at the beginning of the content
instead of at the end. This was caused because the focus method was being
called before the content had actually been rendered to the dom.
- Adds a callback to check when injected comp was actually rendered, and uses
that to focus the body at the correct time.
- Updates specs
- Updates behavior of focusing composer body when selecting threads in split
mode -- resolves #T3444
- It will focus the body when a thread is selcted via a click
- It wont focus the body when a thread is selected via arrow keys
- It will focus the body when a new inline reply is created
- Updates specs
Test Plan: - Unit tests
Reviewers: evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2393
Summary:
- The main purpose of this is to be able to properly register the editor for the markdown plugin (and any other plugins to come)
- Refactors ComposerView and Contenteditable ->
- Replaces Contenteditable with an InjectedComponent for a new region role:
"Composer:Editor"
- Creates a new component called ComposerEditor, which is the one that is
being registered by default as "Composer:Editor"
- I used this class to try to standardize the props that should be
passed to any would be editor Component:
- Renamed a bunch of the props which (I think) had a bit of
confusing names
- Added a bunch of docs for these in the source file, although
I feel like those docs should live elsewhere, like in the
ComponentRegion docs.
- In the process, I ended up pulling some stuff out of ComposerView and
some stuff out of the Contenteditable, namely:
- The scrolling logic to ensure that the composer is visible while
typing was moved outside of the Contenteditable -- this feels more
like the ComposerEditor's responsibility, especially since the
Contenteditable is meant to be used in other contexts as well.
- The ComposerExtensions state; it feels less awkward for me if this
is inside the ComposerEditor because 1) ComposerView does less
things, 2) these are actually just being passed to the
Contenteditable, 3) I feel like other plugins shouldn't need to
mess around with ComposerExtensions, so we shouldn't pass them to the
editor. If you register an editor different from our default one,
any other ComposerExtension callbacks will be disabled, which
I feel is expected behavior.
- I think there is still some more refactoring to be done, and I left some TODOS
here and there, but I think this diff is already big enough and its a minimal
set of changes to get the markdown editor working in a not so duck
tapish way.
- New props for InjectedComponent:
- `requiredMethods`: allows you to define a collection of methods that
should be implemented by any Component that registers for your
desired region.
- It will throw an error if these are not implemented
- It will automatically pass calls made on the InjectedComponent to these methods
down to the instance of the actual registered component
- Would love some comments on this approach and impl
- `fallback`: allows you to define a default component to use if none were
registered through the ComponentRegistry
- Misc:
- Added a new test case for the QuotedHTMLTransformer
- Tests:
- They were minimally updated so that they don't break, but a big TODO
is to properly refactor them. I plan to do that in an upcoming
diff.
Test Plan: - Unit tests
Reviewers: bengotow, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2372
Summary:
Adds the new Account preferences page. This consists of two major React components,
PreferencesAccountList and PreferencesAccountDetails, both of which use EditableList.
I added a bunch of fixes and updated the API for EditableList, plus a bit of
refactoring for PreferencesAccount component, and a bunch of CSS so its a big diff.
The detailed changelog:
Updates to EditableList:
- Fix bug updating selection state when arrows pressed to move selection
- Add new props:
- allowEmptySelection to allow the list to have no selection
- createInputProps to pass aditional props to the createInput
- Add scroll region for list items
- Update styles and refactor render methods
Other Updates:
- Updates Account model to hold aliases and a label
- Adds getter for label to default to email
- Update accountswitcher to display label, update styles and spec
- Refactor PreferencesAccounts component:
- Splits it into smaller components,
- Removes unused code
- Splits preferences styelsheets into smaller separate stylesheet for
account page. Adds some updates and fixes (scroll-region padding)
- Update AccountStore to be able to perform updates on an account.
- Adds new Action to update account, and an action to remove account to
be consistent with Action usage
- Adds components for Account list and Aliases list using EditableList
Test Plan: - All specs pass, but need to write new tests!
Reviewers: bengotow, evan
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2332
Clicking participant fields to type in them did not cause state.focusedField to change, because no onFocus events were bound to the ParticipantTextFields. Since setState was not called, the focus would appear to change but revert as soon as you touched state.
This diff also renames `onChangeEnabledFields` to `onAdjustEnabledFields` making it more clear that unlike the other handlers, it does not take a new value, it takes a set of changes. I also noticed that we /always/ focus fields when showing them, so I removed the separate focus param from it and made it adjust focus at the composer-view level only.
I also consolidated everywhere that touches `state.focusedField` so that we can keep the `_lastFocusedParticipantField` value in sync with it more easily.
- Fixes issue where body lost focus when typing and focus switched to to
field
- Now passes the onFocus handler as part of a `ContenteditableExtension`
Summary:
Related to #320, #494, #515, #553
Ignore newlines and returns in HTML, they can be inside tags
Allow all attributes so that paste from excel looks nice
Never let someone paste a `contenteditable` attribute
Update specs
Test Plan: Run new specs
Reviewers: juan, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2309
comment
Adding test harness
Using key strokes in main window test
Tests work now
Clean up argument variables
Rename list manager and get rid of old spec-helper methods
Extract out time overrides from spec-helper
Spectron test for contenteditable
fix spec exit codes and boot mode
fix(spec): cleanup N1.sh and make specs fail with exit code 1
Revert tests and get it working in window
Move to spec_integration and add window load tester
Specs pass. Console logs still in
Remove console logs
Extract N1 Launcher ready method
Make integrated unit test runner
feat(tests): adding integration tests
Summary:
The /spectron folder got moved to /spec_integration
There are now unit tests (the old ones) run via the renamed
`script/grunt run-unit-tests`
There are now integration tests run via the command `script/grunt
run-integration-tests`.
There are two types of integration tests:
1. Tests that operate on the whole app via Selenium/Chromedriver. These
tests have access to Spectron APIs but do NOT have access to any JS object
running inside the application. See the `app-boot-spec.es6` for an example
of these tests. This is tricky because we want to test the Main window,
but Spectron may latch onto any other of our loading windows. Code in
`integration-helper` give us an API that finds and loads the main window
so we can test it
2. Tests that run in the unit test suite that need Spectron to perform
integration-like behavior. These are the contentedtiable specs. The
Spectron server is accessed from the app and can be used to trigger
actions on the running app, from the app. These tests use the
windowed-test runner so Spectron can identify whether the tests have
completed, passed, or failed. Unfortunately Spectron can't access the logs
, nor the exit code of the test script thereby forcing us to parse the
HTML DOM. (Note this is still a WIP)
I also revamped the `N1.sh` file when getting the launch arguments to work
properly. It's much cleaner. We didn't need most of the data.
Test Plan: new tests
Reviewers: juan, bengotow
Differential Revision: https://phab.nylas.com/D2289
Fix composer specs
Tests can properly detect when Spectron is in the environment
Report plain text output in specs
fixing contenteditable specs
Testing slow keymaps on contenteditable specs
Move to DOm mutation
Spell as `subtree` not `subTree`
Summary: This uses DOM mutation observers instead of `onInput`
Test Plan: manual and new integration tests
Reviewers: bengotow, juan
Differential Revision: https://phab.nylas.com/D2291
feat(contenteditable): add bold, underline, etc keymaps
Moving button extensions out of toolbar
Extracted floating toolbar buttons
Convert ContenteditableExtension to new spec
Update packages to use new callback signature
Fix specs
