Mailspring/app/internal_packages/composer/lib/main.jsx

125 lines
3.6 KiB
React
Raw Normal View History

fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
/* eslint react/sort-comp: 0 */
import _ from 'underscore';
import React from 'react';
import {
Message,
DraftStore,
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
WorkspaceStore,
ComponentRegistry,
ExtensionRegistry,
InflatesDraftClientId,
CustomContenteditableComponents,
} from 'mailspring-exports';
2017-09-27 02:46:00 +08:00
import { OverlaidComposerExtension } from 'mailspring-component-kit';
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
import ComposeButton from './compose-button';
import ComposerView from './composer-view';
import InlineImageComposerExtension from './inline-image-composer-extension';
2017-09-27 02:33:08 +08:00
import InlineImageUploadContainer from './inline-image-upload-container';
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
const ComposerViewForDraftClientId = InflatesDraftClientId(ComposerView);
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
class ComposerWithWindowProps extends React.Component {
static displayName = 'ComposerWithWindowProps';
static containerRequired = false;
constructor(props) {
super(props);
feat(win): faster popout windows Summary: This diff is designed to dramatically speed up new window load time for all window types and reduce memory consumption of our hot windows. Before this diff, windows loaded in ~3 seconds. They now boot in a couple hundred milliseconds without requiring to keep hot windows around for each and every type of popout window we want to load quickly. One of the largest bottlenecks was the `require`ing and initializing of everything in `NylasExports`. I changed `NylasExports` to be entirely lazily-loaded. Drafts and tasks now register their constructors with a `StoreRegistry` and the `TaskRegistry`. This lets us explicitly choose a time to activate these stores in the window initalization instead of whenever nylas-exports happens to be required first. Before, NylasExports was required first when components were first rendering. This made initial render extremely slow and made the proposed time picker popout slow. By moving require into the very initial window boot, we can create a new scheme of hot windows that are "half loaded". All of the expensive require-ing and store initialization is done. All we need to do is activate the packages for just the one window. This means that the hot window scheme needs to fundamentally change from have fully pre-loaded windows, to having half-loaded empty hot windows that can get their window props overridden again. This led to a major refactor of the WindowManager to support this new window scheme. Along the way the API of WindowManager was significantly simplifed. Instead of a bunch of special-cased windows, there are now consistent interfaces to get and `ensure` windows are created and displayed. This DRYed up a lot of repeated logic around showing or creating core windows. This also allowed the consolidation of the core window configurations into one place for much easier reasoning about what's getting booted up. When a hot window goes "live" and gets populated, we simply change the `windowType`. This now re-triggers the loading of all of the packages for the window. All of the loading time is now just for the packages that window requires since core Nylas is there thanks to the hot window mechanism. Unfortunately loading all of the packages for the composer was still unnaceptably slow. The major issue was that all of the composer plugins were taking a long time to process and initialize. The solution was to have the main composer load first, then trigger another window load settings change to change the `windowType` that loads in all of the plugins. Another major bottleneck was the `RetinaImg` name lookup on disk. This requires traversing the entire static folder synchronously on boot. This is now done once when the main window loads and saved in a cache in the browser process. Any secondary windows simply ask the backend for this cache and save the filesystem access time. The Paper Doc below is the current set of manual tests I'm doing to make sure no window interactions (there are a lot of them!) regressed. Test Plan: https://paper.dropbox.com/doc/Window-Refactor-UYsgvjgdXgVlTw8nXTr9h Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2916
2016-04-23 04:30:42 +08:00
// We'll now always have windowProps by the time we construct this.
2017-09-27 02:36:58 +08:00
const windowProps = AppEnv.getWindowProps();
2017-09-27 02:33:08 +08:00
const { draftJSON, headerMessageId } = windowProps;
if (!draftJSON) {
2017-09-27 02:33:08 +08:00
throw new Error('Initialize popout composer windows with valid draftJSON');
}
feat(win): faster popout windows Summary: This diff is designed to dramatically speed up new window load time for all window types and reduce memory consumption of our hot windows. Before this diff, windows loaded in ~3 seconds. They now boot in a couple hundred milliseconds without requiring to keep hot windows around for each and every type of popout window we want to load quickly. One of the largest bottlenecks was the `require`ing and initializing of everything in `NylasExports`. I changed `NylasExports` to be entirely lazily-loaded. Drafts and tasks now register their constructors with a `StoreRegistry` and the `TaskRegistry`. This lets us explicitly choose a time to activate these stores in the window initalization instead of whenever nylas-exports happens to be required first. Before, NylasExports was required first when components were first rendering. This made initial render extremely slow and made the proposed time picker popout slow. By moving require into the very initial window boot, we can create a new scheme of hot windows that are "half loaded". All of the expensive require-ing and store initialization is done. All we need to do is activate the packages for just the one window. This means that the hot window scheme needs to fundamentally change from have fully pre-loaded windows, to having half-loaded empty hot windows that can get their window props overridden again. This led to a major refactor of the WindowManager to support this new window scheme. Along the way the API of WindowManager was significantly simplifed. Instead of a bunch of special-cased windows, there are now consistent interfaces to get and `ensure` windows are created and displayed. This DRYed up a lot of repeated logic around showing or creating core windows. This also allowed the consolidation of the core window configurations into one place for much easier reasoning about what's getting booted up. When a hot window goes "live" and gets populated, we simply change the `windowType`. This now re-triggers the loading of all of the packages for the window. All of the loading time is now just for the packages that window requires since core Nylas is there thanks to the hot window mechanism. Unfortunately loading all of the packages for the composer was still unnaceptably slow. The major issue was that all of the composer plugins were taking a long time to process and initialize. The solution was to have the main composer load first, then trigger another window load settings change to change the `windowType` that loads in all of the plugins. Another major bottleneck was the `RetinaImg` name lookup on disk. This requires traversing the entire static folder synchronously on boot. This is now done once when the main window loads and saved in a cache in the browser process. Any secondary windows simply ask the backend for this cache and save the filesystem access time. The Paper Doc below is the current set of manual tests I'm doing to make sure no window interactions (there are a lot of them!) regressed. Test Plan: https://paper.dropbox.com/doc/Window-Refactor-UYsgvjgdXgVlTw8nXTr9h Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2916
2016-04-23 04:30:42 +08:00
const draft = new Message().fromJSON(draftJSON);
DraftStore._createSession(headerMessageId, draft);
2017-09-27 02:33:08 +08:00
this.state = windowProps;
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
}
componentWillUnmount() {
2017-09-27 02:33:08 +08:00
if (this._usub) {
this._usub();
}
}
componentDidUpdate() {
2017-09-27 02:33:08 +08:00
this._composerComponent.focus();
}
_onDraftReady = () => {
this._composerComponent.focus().then(() => {
2017-09-27 02:36:58 +08:00
AppEnv.displayWindow();
feat(win): faster popout windows Summary: This diff is designed to dramatically speed up new window load time for all window types and reduce memory consumption of our hot windows. Before this diff, windows loaded in ~3 seconds. They now boot in a couple hundred milliseconds without requiring to keep hot windows around for each and every type of popout window we want to load quickly. One of the largest bottlenecks was the `require`ing and initializing of everything in `NylasExports`. I changed `NylasExports` to be entirely lazily-loaded. Drafts and tasks now register their constructors with a `StoreRegistry` and the `TaskRegistry`. This lets us explicitly choose a time to activate these stores in the window initalization instead of whenever nylas-exports happens to be required first. Before, NylasExports was required first when components were first rendering. This made initial render extremely slow and made the proposed time picker popout slow. By moving require into the very initial window boot, we can create a new scheme of hot windows that are "half loaded". All of the expensive require-ing and store initialization is done. All we need to do is activate the packages for just the one window. This means that the hot window scheme needs to fundamentally change from have fully pre-loaded windows, to having half-loaded empty hot windows that can get their window props overridden again. This led to a major refactor of the WindowManager to support this new window scheme. Along the way the API of WindowManager was significantly simplifed. Instead of a bunch of special-cased windows, there are now consistent interfaces to get and `ensure` windows are created and displayed. This DRYed up a lot of repeated logic around showing or creating core windows. This also allowed the consolidation of the core window configurations into one place for much easier reasoning about what's getting booted up. When a hot window goes "live" and gets populated, we simply change the `windowType`. This now re-triggers the loading of all of the packages for the window. All of the loading time is now just for the packages that window requires since core Nylas is there thanks to the hot window mechanism. Unfortunately loading all of the packages for the composer was still unnaceptably slow. The major issue was that all of the composer plugins were taking a long time to process and initialize. The solution was to have the main composer load first, then trigger another window load settings change to change the `windowType` that loads in all of the plugins. Another major bottleneck was the `RetinaImg` name lookup on disk. This requires traversing the entire static folder synchronously on boot. This is now done once when the main window loads and saved in a cache in the browser process. Any secondary windows simply ask the backend for this cache and save the filesystem access time. The Paper Doc below is the current set of manual tests I'm doing to make sure no window interactions (there are a lot of them!) regressed. Test Plan: https://paper.dropbox.com/doc/Window-Refactor-UYsgvjgdXgVlTw8nXTr9h Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2916
2016-04-23 04:30:42 +08:00
if (this.state.errorMessage) {
this._showInitialErrorDialog(this.state.errorMessage, this.state.errorDetail);
feat(win): faster popout windows Summary: This diff is designed to dramatically speed up new window load time for all window types and reduce memory consumption of our hot windows. Before this diff, windows loaded in ~3 seconds. They now boot in a couple hundred milliseconds without requiring to keep hot windows around for each and every type of popout window we want to load quickly. One of the largest bottlenecks was the `require`ing and initializing of everything in `NylasExports`. I changed `NylasExports` to be entirely lazily-loaded. Drafts and tasks now register their constructors with a `StoreRegistry` and the `TaskRegistry`. This lets us explicitly choose a time to activate these stores in the window initalization instead of whenever nylas-exports happens to be required first. Before, NylasExports was required first when components were first rendering. This made initial render extremely slow and made the proposed time picker popout slow. By moving require into the very initial window boot, we can create a new scheme of hot windows that are "half loaded". All of the expensive require-ing and store initialization is done. All we need to do is activate the packages for just the one window. This means that the hot window scheme needs to fundamentally change from have fully pre-loaded windows, to having half-loaded empty hot windows that can get their window props overridden again. This led to a major refactor of the WindowManager to support this new window scheme. Along the way the API of WindowManager was significantly simplifed. Instead of a bunch of special-cased windows, there are now consistent interfaces to get and `ensure` windows are created and displayed. This DRYed up a lot of repeated logic around showing or creating core windows. This also allowed the consolidation of the core window configurations into one place for much easier reasoning about what's getting booted up. When a hot window goes "live" and gets populated, we simply change the `windowType`. This now re-triggers the loading of all of the packages for the window. All of the loading time is now just for the packages that window requires since core Nylas is there thanks to the hot window mechanism. Unfortunately loading all of the packages for the composer was still unnaceptably slow. The major issue was that all of the composer plugins were taking a long time to process and initialize. The solution was to have the main composer load first, then trigger another window load settings change to change the `windowType` that loads in all of the plugins. Another major bottleneck was the `RetinaImg` name lookup on disk. This requires traversing the entire static folder synchronously on boot. This is now done once when the main window loads and saved in a cache in the browser process. Any secondary windows simply ask the backend for this cache and save the filesystem access time. The Paper Doc below is the current set of manual tests I'm doing to make sure no window interactions (there are a lot of them!) regressed. Test Plan: https://paper.dropbox.com/doc/Window-Refactor-UYsgvjgdXgVlTw8nXTr9h Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2916
2016-04-23 04:30:42 +08:00
}
});
2017-09-27 02:33:08 +08:00
};
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
render() {
return (
<ComposerViewForDraftClientId
2017-09-27 02:33:08 +08:00
ref={cm => {
this._composerComponent = cm;
}}
onDraftReady={this._onDraftReady}
headerMessageId={this.state.headerMessageId}
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
className="composer-full-window"
/>
);
}
_showInitialErrorDialog(msg, detail) {
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
// We delay so the view has time to update the restored draft. If we
// don't delay the modal may come up in a state where the draft looks
// like it hasn't been restored or has been lost.
_.delay(() => {
2017-09-27 02:36:58 +08:00
AppEnv.showErrorDialog({ title: 'Error', message: msg }, { detail: detail });
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
}, 100);
}
}
export function activate() {
2017-09-27 02:36:58 +08:00
if (AppEnv.isMainWindow()) {
ComponentRegistry.register(ComposerViewForDraftClientId, {
role: 'Composer',
});
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
ComponentRegistry.register(ComposeButton, {
location: WorkspaceStore.Location.RootSidebar.Toolbar,
});
2017-09-27 02:36:58 +08:00
} else if (AppEnv.isThreadWindow()) {
ComponentRegistry.register(ComposerViewForDraftClientId, {
role: 'Composer',
});
} else {
2017-09-27 02:36:58 +08:00
AppEnv.getCurrentWindow().setMinimumSize(480, 250);
ComponentRegistry.register(ComposerWithWindowProps, {
location: WorkspaceStore.Location.Center,
});
2016-04-23 08:39:29 +08:00
}
2017-09-27 02:33:08 +08:00
ExtensionRegistry.Composer.register(OverlaidComposerExtension, { priority: 1 });
ExtensionRegistry.Composer.register(InlineImageComposerExtension);
2017-09-27 02:33:08 +08:00
CustomContenteditableComponents.register(
'InlineImageUploadContainer',
InlineImageUploadContainer
);
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
}
export function deactivate() {
2017-09-27 02:36:58 +08:00
if (AppEnv.isMainWindow()) {
ComponentRegistry.unregister(ComposerViewForDraftClientId);
ComponentRegistry.unregister(ComposeButton);
} else {
ComponentRegistry.unregister(ComposerWithWindowProps);
}
feat(undo-send): Add undo send Summary: Add ability to undo send. We decided to make undo send completely client side for a couple of reasons. If we rely on send-later for undo-send, we would be giving /all/ send load to our send-later backend. If this increases the send-later load too much, it might cause delays in the regular send-later functionality and potentially other plugins like snooze that run under the same service. We would also need to rely on the network to be able to cancel a send, which would make it unusable offline or hard to debug if that specific request fails for any given reason. This commit also refactors the way `ComposerExtension.sendActionConfig` works. The method has been renamed and now must return an array of send actions. Also, all of the business logic to handle different send actions registered by extensions has been pieced apart from the SendActionButton and into a new SendActionStore. This also enables undo send to undo custom send actions registered by extensions. Along the way, this also fixes a pending TODO to show all registered custom send actions in the preferences for choosing the preferred send action for sending. Undo send works via a task, so in case N1 closes before send goes through, it will still be persisted to the task queue and restored when opened again. Undoing a send means dequeuing this task. Test Plan: Manual Reviewers: jackie, bengotow, halla, evan Reviewed By: bengotow, halla, evan Differential Revision: https://phab.nylas.com/D3361
2016-10-22 02:48:04 +08:00
2017-09-27 02:33:08 +08:00
ExtensionRegistry.Composer.unregister(OverlaidComposerExtension);
ExtensionRegistry.Composer.unregister(InlineImageComposerExtension);
2017-09-27 02:33:08 +08:00
CustomContenteditableComponents.unregister('InlineImageUploadContainer');
fix(focus): Remove focusedField in favor of imperative focus, break apart ComposerView Summary: - Removes controlled focus in the composer! - No React components ever perfom focus in lifecycle methods. Never again. - A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus" - The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus. - The MessageList never focuses anything automatically. - Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView - ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon. - Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing. - Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want. - Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature. Todos: - Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur. - Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable. - Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon. Test Plan: Broken Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2814
2016-04-05 06:22:01 +08:00
}
export function serialize() {
return this.state;
}