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 React from 'react';
|
|
|
|
import ReactDOM from 'react-dom';
|
|
|
|
import ReactTestUtils from 'react-addons-test-utils';
|
|
|
|
|
|
|
|
import {Contact, Message} from 'nylas-exports';
|
|
|
|
import ComposerHeader from '../lib/composer-header';
|
|
|
|
import Fields from '../lib/fields';
|
|
|
|
|
2016-05-05 05:03:15 +08:00
|
|
|
describe('ComposerHeader', function composerHeader() {
|
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
|
|
|
beforeEach(() => {
|
|
|
|
this.createWithDraft = (draft) => {
|
|
|
|
const session = {
|
|
|
|
changes: {
|
|
|
|
add: jasmine.createSpy('changes.add'),
|
|
|
|
},
|
|
|
|
};
|
|
|
|
this.component = ReactTestUtils.renderIntoDocument(
|
|
|
|
<ComposerHeader
|
|
|
|
draft={draft}
|
2016-04-30 07:54:37 +08:00
|
|
|
initiallyFocused={false}
|
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
|
|
|
session={session}
|
|
|
|
/>
|
|
|
|
)
|
|
|
|
};
|
|
|
|
advanceClock()
|
|
|
|
});
|
|
|
|
|
|
|
|
describe("showAndFocusField", () => {
|
|
|
|
beforeEach(() => {
|
2016-09-21 06:17:45 +08:00
|
|
|
const draft = new Message({
|
|
|
|
draft: true,
|
|
|
|
accountId: TEST_ACCOUNT_ID,
|
|
|
|
});
|
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
|
|
|
this.createWithDraft(draft);
|
|
|
|
});
|
|
|
|
|
|
|
|
it("should ensure the field is in enabledFields", () => {
|
|
|
|
expect(this.component.state.enabledFields).toEqual(['textFieldTo', 'fromField', 'textFieldSubject'])
|
|
|
|
this.component.showAndFocusField(Fields.Bcc);
|
|
|
|
expect(this.component.state.enabledFields).toEqual(['textFieldTo', 'fromField', 'textFieldSubject', 'textFieldBcc'])
|
|
|
|
});
|
|
|
|
|
|
|
|
it("should ensure participantsFocused is true if necessary", () => {
|
|
|
|
expect(this.component.state.participantsFocused).toEqual(false);
|
|
|
|
this.component.showAndFocusField(Fields.Subject);
|
|
|
|
expect(this.component.state.participantsFocused).toEqual(false);
|
|
|
|
this.component.showAndFocusField(Fields.Bcc);
|
|
|
|
expect(this.component.state.participantsFocused).toEqual(true);
|
|
|
|
});
|
|
|
|
|
|
|
|
it("should wait for the field to become available and then focus it", () => {
|
|
|
|
const $el = ReactDOM.findDOMNode(this.component);
|
|
|
|
expect($el.querySelector('.bcc-field')).toBe(null);
|
|
|
|
this.component.showAndFocusField(Fields.Bcc);
|
|
|
|
advanceClock();
|
|
|
|
expect($el.querySelector('.bcc-field')).not.toBe(null);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
describe("hideField", () => {
|
|
|
|
beforeEach(() => {
|
|
|
|
const draft = new Message({draft: true, accountId: TEST_ACCOUNT_ID});
|
|
|
|
this.createWithDraft(draft);
|
|
|
|
});
|
|
|
|
|
|
|
|
it("should remove the field from enabledFields", () => {
|
|
|
|
const $el = ReactDOM.findDOMNode(this.component);
|
|
|
|
|
|
|
|
this.component.showAndFocusField(Fields.Bcc);
|
|
|
|
advanceClock();
|
|
|
|
expect($el.querySelector('.bcc-field')).not.toBe(null);
|
|
|
|
this.component.hideField(Fields.Bcc);
|
|
|
|
advanceClock();
|
|
|
|
expect($el.querySelector('.bcc-field')).toBe(null);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
describe("initial state", () => {
|
|
|
|
it("should enable any fields that are populated", () => {
|
|
|
|
let draft = null;
|
|
|
|
|
|
|
|
draft = new Message({draft: true, accountId: TEST_ACCOUNT_ID});
|
|
|
|
this.createWithDraft(draft);
|
|
|
|
expect(this.component.state.enabledFields).toEqual(['textFieldTo', 'fromField', 'textFieldSubject'])
|
|
|
|
|
2016-09-21 06:17:45 +08:00
|
|
|
draft = new Message({
|
|
|
|
draft: true,
|
|
|
|
cc: [new Contact({id: 'a', email: 'a'})],
|
2016-09-21 07:34:30 +08:00
|
|
|
bcc: [new Contact({id: 'b', email: 'b'})],
|
2016-09-21 06:17:45 +08:00
|
|
|
accountId: TEST_ACCOUNT_ID,
|
|
|
|
});
|
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
|
|
|
this.createWithDraft(draft);
|
|
|
|
expect(this.component.state.enabledFields).toEqual(['textFieldTo', 'textFieldCc', 'textFieldBcc', 'fromField', 'textFieldSubject'])
|
|
|
|
});
|
|
|
|
|
|
|
|
describe("subject", () => {
|
|
|
|
it("should be enabled if it is empty", () => {
|
|
|
|
const draft = new Message({draft: true, subject: '', accountId: TEST_ACCOUNT_ID});
|
|
|
|
this.createWithDraft(draft);
|
|
|
|
expect(this.component.state.enabledFields).toEqual(['textFieldTo', 'fromField', 'textFieldSubject'])
|
|
|
|
});
|
|
|
|
|
|
|
|
it("should be enabled if the message is a forward", () => {
|
|
|
|
const draft = new Message({draft: true, subject: 'Fwd: 1234', accountId: TEST_ACCOUNT_ID});
|
|
|
|
this.createWithDraft(draft);
|
|
|
|
expect(this.component.state.enabledFields).toEqual(['textFieldTo', 'fromField', 'textFieldSubject'])
|
|
|
|
});
|
|
|
|
|
|
|
|
it("should be hidden if the message is a reply", () => {
|
|
|
|
const draft = new Message({draft: true, subject: 'Re: 1234', replyToMessageId: '123', accountId: TEST_ACCOUNT_ID});
|
|
|
|
this.createWithDraft(draft);
|
|
|
|
expect(this.component.state.enabledFields).toEqual(['textFieldTo', 'fromField'])
|
|
|
|
});
|
|
|
|
});
|
|
|
|
});
|
|
|
|
});
|