Mailspring/app/internal_packages/participant-profile/lib/sidebar-related-threads.jsx

76 lines
2.1 KiB
React
Raw Normal View History

feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
import React from 'react'
Better support 24-hour time (#2622) * Added support for 24-hour time to the thread list view (Issue #682) * Add 24-hour time support to the thread list scroll tooltip (Issue #682) * Fix for 24-hour time in the thread list scroll tooltip (#682) Correctly imports the DateUtils module * Add support for 24-hour time to the draft threads list (Issue #682) * Add 24-hour time to the message sidebar * Fix for 24-hour time in the message view so the rollover tooltip is 24hour also (#682) * Removed unused date functions from utils fullTimeString and shortTimeString from src/flux/models/utils.coffee were not compatible with 24-hour time. These functions were modified and moved to DateUtils in src/date-utils. * Fix for display of 24-hour time in the message view (Issue #682) * Removed unused import of Utils in a couple of files Prompted by Travis build errors. * Updates to handling of date/time display Incorporates changes suggested by @bengotow. Re-enables support for the isDetailed property in message-timestamp (if this is set to true, a medium length date/time string will be used for display). Re-enables additional display varieties based on when the email was received. Note that this is implemented slightly different to the orinal version - time is now given as an absolute time rather than "... days ago" format. TZ guessing moved to the global scope of date-utils for performance reasons. * Minor de-linting * Re-enable all tests by unfocusing the test suite A previous commit (ad04775) added an fdescribe() to one of the tests in draft-helpers-spec. This changes that to a regular describe() so that all tests will be run when running ./N1 --test. * Added tests for the new DateUtils functions Added tests for getTimeFormat, mediumTimeString and fullTimeString. Removed no longer relevant tests from message-timestamp-spec as _formattedDate has been removed in favour of the functions in date-utils. To test shortTimeString, we need to be able to set a fake current time which is possible in jasmine 2.0+ but not in 1.3 which is currently in use. As a possible bug, when running more than 10 tests the following warning is raised: "(node:25025) Warning: Possible EventEmitter memory leak detected. 11 on-config-reloaded listeners added. Use emitter.setMaxListeners() to increase limit", source: internal/process/warning.js (24) * Minor de-linting
2016-07-29 08:42:14 +08:00
import {Actions, DateUtils} from 'nylas-exports'
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
export default class RelatedThreads extends React.Component {
static displayName = "RelatedThreads";
static propTypes = {
contact: React.PropTypes.object,
contactThreads: React.PropTypes.array,
}
2016-05-07 07:06:16 +08:00
static containerStyles = {
order: 99,
}
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
constructor(props) {
super(props)
this.state = {expanded: false}
this.DEFAULT_NUM = 3
}
_onClick(thread) {
Actions.setFocus({collection: 'thread', item: thread})
}
_toggle = () => {
this.setState({expanded: !this.state.expanded})
}
_renderToggle() {
if (!this._hasToggle()) { return false; }
const msg = this.state.expanded ? "Collapse" : "Show more"
return (
<div className="toggle" onClick={this._toggle}>{msg}</div>
)
}
_hasToggle() {
return (this.props.contactThreads.length > this.DEFAULT_NUM)
}
render() {
let limit;
if (this.state.expanded) {
limit = this.props.contactThreads.length;
} else {
limit = Math.min(this.props.contactThreads.length, this.DEFAULT_NUM)
}
2016-03-11 04:06:44 +08:00
const height = ((limit + (this._hasToggle() ? 1 : 0)) * 31);
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
const shownThreads = this.props.contactThreads.slice(0, limit)
const threads = shownThreads.map((thread) => {
const {snippet, subject, lastMessageReceivedTimestamp} = thread;
const snippetStyles = (subject && subject.length) ? {marginLeft: '1em'} : {};
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
const onClick = () => { this._onClick(thread) }
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
return (
<div key={thread.id} className="related-thread" onClick={onClick} >
<span className="content" title={subject}>
{subject}
<span className="snippet" style={snippetStyles}>{snippet}</span>
</span>
Better support 24-hour time (#2622) * Added support for 24-hour time to the thread list view (Issue #682) * Add 24-hour time support to the thread list scroll tooltip (Issue #682) * Fix for 24-hour time in the thread list scroll tooltip (#682) Correctly imports the DateUtils module * Add support for 24-hour time to the draft threads list (Issue #682) * Add 24-hour time to the message sidebar * Fix for 24-hour time in the message view so the rollover tooltip is 24hour also (#682) * Removed unused date functions from utils fullTimeString and shortTimeString from src/flux/models/utils.coffee were not compatible with 24-hour time. These functions were modified and moved to DateUtils in src/date-utils. * Fix for display of 24-hour time in the message view (Issue #682) * Removed unused import of Utils in a couple of files Prompted by Travis build errors. * Updates to handling of date/time display Incorporates changes suggested by @bengotow. Re-enables support for the isDetailed property in message-timestamp (if this is set to true, a medium length date/time string will be used for display). Re-enables additional display varieties based on when the email was received. Note that this is implemented slightly different to the orinal version - time is now given as an absolute time rather than "... days ago" format. TZ guessing moved to the global scope of date-utils for performance reasons. * Minor de-linting * Re-enable all tests by unfocusing the test suite A previous commit (ad04775) added an fdescribe() to one of the tests in draft-helpers-spec. This changes that to a regular describe() so that all tests will be run when running ./N1 --test. * Added tests for the new DateUtils functions Added tests for getTimeFormat, mediumTimeString and fullTimeString. Removed no longer relevant tests from message-timestamp-spec as _formattedDate has been removed in favour of the functions in date-utils. To test shortTimeString, we need to be able to set a fake current time which is possible in jasmine 2.0+ but not in 1.3 which is currently in use. As a possible bug, when running more than 10 tests the following warning is raised: "(node:25025) Warning: Possible EventEmitter memory leak detected. 11 on-config-reloaded listeners added. Use emitter.setMaxListeners() to increase limit", source: internal/process/warning.js (24) * Minor de-linting
2016-07-29 08:42:14 +08:00
<span className="timestamp" title={DateUtils.fullTimeString(lastMessageReceivedTimestamp)}>{DateUtils.shortTimeString(lastMessageReceivedTimestamp)}</span>
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
</div>
)
})
return (
<div className="related-threads" style={{height}}>
{threads}
{this._renderToggle()}
</div>
)
}
}