Mailspring/spec/components/editable-list-spec.jsx

288 lines
10 KiB
React
Raw Normal View History

import React from 'react';
import ReactDOM from 'react-dom';
import {
findRenderedDOMComponentWithClass,
scryRenderedDOMComponentsWithClass,
Simulate,
} from 'react-addons-test-utils';
import EditableList from '../../src/components/editable-list';
import {renderIntoDocument, simulateCommand} from '../nylas-test-utils'
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
const {findDOMNode} = ReactDOM;
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
2016-05-06 13:30:34 +08:00
const makeList = (items = [], props = {}) => {
const list = renderIntoDocument(<EditableList {...props} items={items} />);
if (props.initialState) {
list.setState(props.initialState)
}
return list
};
describe('EditableList', function editableList() {
2016-05-06 13:30:34 +08:00
describe('_onItemClick', () => {
it('calls onSelectItem', () => {
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
const onSelectItem = jasmine.createSpy('onSelectItem');
const list = makeList(['1', '2'], {onSelectItem});
const item = scryRenderedDOMComponentsWithClass(list, 'editable-item')[0];
Simulate.click(item);
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
expect(onSelectItem).toHaveBeenCalledWith('1', 0);
});
});
2016-05-06 13:30:34 +08:00
describe('_onItemEdit', () => {
it('enters editing mode when double click', () => {
const list = makeList(['1', '2']);
spyOn(list, 'setState');
const item = scryRenderedDOMComponentsWithClass(list, 'editable-item')[0];
Simulate.doubleClick(item);
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
expect(list.setState).toHaveBeenCalledWith({editingIndex: 0});
});
2016-05-06 13:30:34 +08:00
it('enters editing mode when edit icon clicked', () => {
const list = makeList(['1', '2']);
spyOn(list, 'setState');
const editIcon = scryRenderedDOMComponentsWithClass(list, 'edit-icon')[0];
Simulate.click(editIcon);
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
expect(list.setState).toHaveBeenCalledWith({editingIndex: 0});
});
});
2016-05-06 13:30:34 +08:00
describe('core:previous-item / core:next-item', () => {
it('calls onSelectItem', () => {
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
const onSelectItem = jasmine.createSpy('onSelectItem');
const list = makeList(['1', '2'], {selected: '1', onSelectItem});
const innerList = findRenderedDOMComponentWithClass(list, 'items-wrapper');
simulateCommand(innerList, 'core:next-item')
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
expect(onSelectItem).toHaveBeenCalledWith('2', 1);
});
2016-05-06 13:30:34 +08:00
it('does not select an item when at the bottom of the list and moves down', () => {
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
const onSelectItem = jasmine.createSpy('onSelectItem');
const list = makeList(['1', '2'], {selected: '2', onSelectItem});
const innerList = findRenderedDOMComponentWithClass(list, 'items-wrapper');
simulateCommand(innerList, 'core:next-item')
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
expect(onSelectItem).not.toHaveBeenCalled();
});
2016-05-06 13:30:34 +08:00
it('does not select an item when at the top of the list and moves up', () => {
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
const onSelectItem = jasmine.createSpy('onSelectItem');
const list = makeList(['1', '2'], {selected: '1', onSelectItem});
const innerList = findRenderedDOMComponentWithClass(list, 'items-wrapper');
simulateCommand(innerList, 'core:previous-item')
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
expect(onSelectItem).not.toHaveBeenCalled();
});
2016-05-06 13:30:34 +08:00
it('does not clear the selection when esc pressed but prop does not allow it', () => {
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
const onSelectItem = jasmine.createSpy('onSelectItem');
const list = makeList(['1', '2'], {selected: '1', allowEmptySelection: false, onSelectItem});
const innerList = findRenderedDOMComponentWithClass(list, 'items-wrapper');
Simulate.keyDown(innerList, {key: 'Escape'});
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
expect(onSelectItem).not.toHaveBeenCalled();
});
});
2016-05-06 13:30:34 +08:00
describe('_onCreateInputKeyDown', () => {
it('calls onItemCreated', () => {
const onItemCreated = jasmine.createSpy('onItemCreated');
const list = makeList(['1', '2'], {initialState: {creatingItem: true}, onItemCreated});
const createItem = findRenderedDOMComponentWithClass(list, 'create-item-input');
const input = createItem.querySelector('input');
findDOMNode(input).value = 'New Item';
Simulate.keyDown(input, {key: 'Enter'});
expect(onItemCreated).toHaveBeenCalledWith('New Item');
});
2016-05-06 13:30:34 +08:00
it('does not call onItemCreated when no value entered', () => {
const onItemCreated = jasmine.createSpy('onItemCreated');
const list = makeList(['1', '2'], {initialState: {creatingItem: true}, onItemCreated});
const createItem = findRenderedDOMComponentWithClass(list, 'create-item-input');
const input = createItem.querySelector('input');
findDOMNode(input).value = '';
Simulate.keyDown(input, {key: 'Enter'});
expect(onItemCreated).not.toHaveBeenCalled();
});
});
2016-05-06 13:30:34 +08:00
describe('_onCreateItem', () => {
it('should call prop callback when provided', () => {
const onCreateItem = jasmine.createSpy('onCreateItem');
const list = makeList(['1', '2'], {onCreateItem});
list._onCreateItem();
expect(onCreateItem).toHaveBeenCalled();
});
2016-05-06 13:30:34 +08:00
it('should set state for creating item when no callback provided', () => {
const list = makeList(['1', '2']);
spyOn(list, 'setState');
list._onCreateItem();
expect(list.setState).toHaveBeenCalledWith({creatingItem: true});
});
});
refactor(signatures): Removed old signature imgs and made static empty signatures page 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
2016-07-12 03:28:37 +08:00
describe('_onDeleteItem', () => {
let onSelectItem;
let onDeleteItem;
beforeEach(() => {
onSelectItem = jasmine.createSpy('onSelectItem');
onDeleteItem = jasmine.createSpy('onDeleteItem');
})
it('deletes the item from the list', () => {
const list = makeList(['1', '2'], {selected: '2', onDeleteItem, onSelectItem});
const button = scryRenderedDOMComponentsWithClass(list, 'btn-editable-list')[1];
Simulate.click(button);
expect(onDeleteItem).toHaveBeenCalledWith('2', 1);
})
it('sets the selected item to the one above if it exists', () => {
const list = makeList(['1', '2'], {selected: '2', onDeleteItem, onSelectItem});
const button = scryRenderedDOMComponentsWithClass(list, 'btn-editable-list')[1];
Simulate.click(button);
expect(onSelectItem).toHaveBeenCalledWith('1', 0)
})
it('sets the selected item to the one below if it is at the top', () => {
const list = makeList(['1', '2'], {selected: '1', onDeleteItem, onSelectItem});
const button = scryRenderedDOMComponentsWithClass(list, 'btn-editable-list')[1];
Simulate.click(button);
expect(onSelectItem).toHaveBeenCalledWith('2', 1)
})
it('sets the selected item to nothing when you delete the last item', () => {
const list = makeList(['1'], {selected: '1', onDeleteItem, onSelectItem});
const button = scryRenderedDOMComponentsWithClass(list, 'btn-editable-list')[1];
Simulate.click(button);
expect(onSelectItem).not.toHaveBeenCalled()
})
})
2016-05-06 13:30:34 +08:00
describe('_renderItem', () => {
const makeItem = (item, idx, state = {}, handlers = {}) => {
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
const list = makeList([], {initialState: state});
return renderIntoDocument(
list._renderItem(item, idx, state, handlers)
);
};
2016-05-06 13:30:34 +08:00
it('binds correct click callbacks', () => {
const onClick = jasmine.createSpy('onClick');
const onEdit = jasmine.createSpy('onEdit');
const item = makeItem('item 1', 0, {}, {onClick, onEdit});
Simulate.click(item);
expect(onClick.calls[0].args[1]).toEqual('item 1');
expect(onClick.calls[0].args[2]).toEqual(0);
Simulate.doubleClick(item);
expect(onEdit.calls[0].args[1]).toEqual('item 1');
expect(onEdit.calls[0].args[2]).toEqual(0);
});
2016-05-06 13:30:34 +08:00
it('renders correctly when item is selected', () => {
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
const item = findDOMNode(makeItem('item 1', 0, {selected: 'item 1'}));
expect(item.className.indexOf('selected')).not.toEqual(-1);
});
2016-05-06 13:30:34 +08:00
it('renders correctly when item is string', () => {
const item = findDOMNode(makeItem('item 1', 0));
expect(item.className.indexOf('selected')).toEqual(-1);
expect(item.className.indexOf('editable-item')).not.toEqual(-1);
2016-04-13 07:58:45 +08:00
expect(item.innerText).toEqual('item 1');
});
2016-05-06 13:30:34 +08:00
it('renders correctly when item is component', () => {
2016-10-18 08:59:33 +08:00
const item = findDOMNode(makeItem(<div />, 0));
expect(item.className.indexOf('selected')).toEqual(-1);
expect(item.className.indexOf('editable-item')).toEqual(-1);
expect(item.childNodes[0].tagName).toEqual('DIV');
});
2016-05-06 13:30:34 +08:00
it('renders correctly when item is in editing state', () => {
const onInputBlur = jasmine.createSpy('onInputBlur');
const onInputFocus = jasmine.createSpy('onInputFocus');
const onInputKeyDown = jasmine.createSpy('onInputKeyDown');
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
const item = makeItem('item 1', 0, {editingIndex: 0}, {onInputBlur, onInputFocus, onInputKeyDown});
const input = item.querySelector('input')
Simulate.focus(input);
Simulate.keyDown(input);
Simulate.blur(input);
expect(onInputFocus).toHaveBeenCalled();
expect(onInputBlur).toHaveBeenCalled();
expect(onInputKeyDown.calls[0].args[1]).toEqual('item 1');
expect(onInputKeyDown.calls[0].args[2]).toEqual(0);
expect(findDOMNode(input).tagName).toEqual('INPUT');
});
});
2016-05-06 13:30:34 +08:00
describe('render', () => {
it('renders list of items', () => {
const items = ['1', '2', '3'];
const list = makeList(items);
const innerList = findDOMNode(
feat(account-prefs): Adds new page for Account in preferences 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
2015-12-10 04:35:40 +08:00
findRenderedDOMComponentWithClass(list, 'scroll-region-content-inner')
);
2016-05-06 13:30:34 +08:00
expect(() => {
findRenderedDOMComponentWithClass(list, 'create-item-input');
}).toThrow();
expect(innerList.childNodes.length).toEqual(3);
2016-05-06 13:30:34 +08:00
items.forEach((item, idx) => expect(innerList.childNodes[idx].textContent).toEqual(item));
});
2016-05-06 13:30:34 +08:00
it('renders create input as an item when creating', () => {
const items = ['1', '2', '3'];
const list = makeList(items, {initialState: {creatingItem: true}});
const createItem = findRenderedDOMComponentWithClass(list, 'create-item-input');
expect(createItem).toBeDefined();
});
2016-05-06 13:30:34 +08:00
it('renders add button', () => {
const list = makeList();
const button = scryRenderedDOMComponentsWithClass(list, 'btn-editable-list')[0];
expect(findDOMNode(button).textContent).toEqual('+');
});
2016-05-06 13:30:34 +08:00
it('renders delete button', () => {
refactor(signatures): Removed old signature imgs and made static empty signatures page 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
2016-07-12 03:28:37 +08:00
const list = makeList(['1', '2'], {selected: '2'});
const button = scryRenderedDOMComponentsWithClass(list, 'btn-editable-list')[1];
expect(findDOMNode(button).textContent).toEqual('—');
});
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
refactor(signatures): Removed old signature imgs and made static empty signatures page 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
2016-07-12 03:28:37 +08:00
it('disables the delete button when no item is selected', () => {
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
const onSelectItem = jasmine.createSpy('onSelectItem');
const onDeleteItem = jasmine.createSpy('onDeleteItem');
const list = makeList(['1', '2'], {selected: null, onDeleteItem, onSelectItem});
const button = scryRenderedDOMComponentsWithClass(list, 'btn-editable-list')[1];
Simulate.click(button);
expect(onDeleteItem).not.toHaveBeenCalledWith('2', 1);
});
});
});