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

212 lines
5.6 KiB
React
Raw Normal View History

import { React, PropTypes, DOMUtils, RegExpUtils, Utils } from 'mailspring-exports';
2017-09-27 02:46:00 +08:00
import { RetinaImg } from 'mailspring-component-kit';
2017-09-27 02:33:08 +08:00
import ParticipantProfileStore from './participant-profile-store';
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 SidebarParticipantProfile extends React.Component {
2017-09-27 02:33:08 +08:00
static displayName = 'SidebarParticipantProfile';
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
static propTypes = {
2017-09-27 02:33:08 +08:00
contact: PropTypes.object,
contactThreads: PropTypes.array,
};
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
2016-05-07 07:06:16 +08:00
static containerStyles = {
order: 0,
2017-09-27 02:33:08 +08:00
};
2016-05-07 07:06:16 +08:00
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);
/* We expect ParticipantProfileStore.dataForContact to return the
* following schema:
* {
* profilePhotoUrl: string
* bio: string
* location: string
* currentTitle: string
* currentEmployer: string
* socialProfiles: hash keyed by type: ('twitter', 'facebook' etc)
* url: string
* handle: string
* }
*/
2017-09-27 02:33:08 +08:00
this.state = ParticipantProfileStore.dataForContact(props.contact);
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
}
componentDidMount() {
this.usub = ParticipantProfileStore.listen(() => {
2017-09-27 02:33:08 +08:00
this.setState(ParticipantProfileStore.dataForContact(this.props.contact));
});
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
}
componentWillUnmount() {
2017-09-27 02:33:08 +08:00
this.usub();
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
}
_renderProfilePhoto() {
if (this.state.profilePhotoUrl) {
return (
<div className="profile-photo-wrap">
<div className="profile-photo">
2016-05-07 07:06:16 +08:00
<img alt="Profile" src={this.state.profilePhotoUrl} />
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>
</div>
2017-09-27 02:33:08 +08:00
);
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
}
2017-09-27 02:33:08 +08:00
return this._renderDefaultProfileImage();
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
}
_renderDefaultProfileImage() {
const hue = Utils.hueForString(this.props.contact.email);
2017-09-27 02:33:08 +08:00
const bgColor = `hsl(${hue}, 50%, 45%)`;
const abv = this.props.contact.nameAbbreviation();
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 className="profile-photo-wrap">
<div className="profile-photo">
2017-09-27 02:33:08 +08:00
<div className="default-profile-image" style={{ backgroundColor: bgColor }}>
2016-05-07 07:06:16 +08:00
{abv}
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>
</div>
</div>
2017-09-27 02:33:08 +08:00
);
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
}
_renderCorePersonalInfo() {
2016-03-11 04:06:44 +08:00
const fullName = this.props.contact.fullName();
let renderName = false;
if (fullName !== this.props.contact.email) {
2017-09-27 02:33:08 +08:00
renderName = (
<div className="selectable full-name" onClick={this._select}>
{this.props.contact.fullName()}
</div>
);
2016-03-11 04:06:44 +08:00
}
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 className="core-personal-info">
2016-03-11 04:06:44 +08:00
{renderName}
2017-09-27 02:33:08 +08:00
<div className="selectable email" onClick={this._select}>
{this.props.contact.email}
</div>
{this._renderSocialProfiles()}
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>
2017-09-27 02:33:08 +08:00
);
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
}
_renderSocialProfiles() {
if (!this.state.socialProfiles) {
return false;
}
const profiles = Object.entries(this.state.socialProfiles).map(([type, profile]) => {
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 (
2017-09-27 02:33:08 +08:00
<a className="social-profile-item" key={type} title={profile.url} href={profile.url}>
2016-05-07 07:06:16 +08:00
<RetinaImg
url={`mailspring://participant-profile/assets/${type}-sidebar-icon@2x.png`}
2016-05-07 07:06:16 +08:00
mode={RetinaImg.Mode.ContentPreserve}
/>
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
</a>
2017-09-27 02:33:08 +08:00
);
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
});
2017-09-27 02:33:08 +08:00
return <div className="social-profiles-wrap">{profiles}</div>;
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
}
_renderAdditionalInfo() {
return (
<div className="additional-info">
{this._renderCurrentJob()}
{this._renderBio()}
{this._renderLocation()}
</div>
2017-09-27 02:33:08 +08:00
);
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
}
_renderCurrentJob() {
2017-09-27 02:33:08 +08:00
if (!this.state.employer) {
return false;
}
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
let title = false;
if (this.state.title) {
2017-09-27 02:33:08 +08:00
title = <span>{this.state.title},&nbsp;</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
}
return (
2017-09-27 02:33:08 +08:00
<p className="selectable current-job">
{title}
{this.state.employer}
</p>
);
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
}
_renderBio() {
2017-09-27 02:33:08 +08:00
if (!this.state.bio) {
return false;
}
const bioNodes = [];
const hashtagOrMentionRegex = RegExpUtils.hashtagOrMentionRegex();
let bioRemainder = this.state.bio;
let match = null;
let count = 0;
/* I thought we were friends. */
/* eslint no-cond-assign: 0 */
2017-09-27 02:33:08 +08:00
while ((match = hashtagOrMentionRegex.exec(bioRemainder))) {
// the first char of the match is whitespace, match[1] is # or @, match[2] is the tag itself.
bioNodes.push(bioRemainder.substr(0, match.index + 1));
if (match[1] === '#') {
2017-09-27 02:33:08 +08:00
bioNodes.push(
<a key={count} href={`https://twitter.com/hashtag/${match[2]}`}>{`#${match[2]}`}</a>
);
}
if (match[1] === '@') {
bioNodes.push(<a key={count} href={`https://twitter.com/${match[2]}`}>{`@${match[2]}`}</a>);
}
bioRemainder = bioRemainder.substr(match.index + match[0].length);
count += 1;
}
bioNodes.push(bioRemainder);
2017-09-27 02:33:08 +08:00
return <p className="selectable bio">{bioNodes}</p>;
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
}
_renderLocation() {
2017-09-27 02:33:08 +08:00
if (!this.state.location) {
return false;
}
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 (
<p className="location">
2016-05-07 07:06:16 +08:00
<RetinaImg
url={`mailspring://participant-profile/assets/location-icon@2x.png`}
2016-05-07 07:06:16 +08:00
mode={RetinaImg.Mode.ContentPreserve}
2017-09-27 02:33:08 +08:00
style={{ float: 'left' }}
2016-05-07 07:06:16 +08:00
/>
2017-09-27 02:33:08 +08:00
<span className="selectable" style={{ display: 'block', marginLeft: 20 }}>
{this.state.location}
</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
</p>
2017-09-27 02:33:08 +08:00
);
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
}
_select(event) {
const el = event.target;
2017-09-27 02:33:08 +08:00
const sel = document.getSelection();
if (el.contains(sel.anchorNode) && !sel.isCollapsed) {
2017-09-27 02:33:08 +08:00
return;
}
2017-09-27 02:33:08 +08:00
const anchor = DOMUtils.findFirstTextNode(el);
const focus = DOMUtils.findLastTextNode(el);
if (anchor && focus && focus.data) {
2017-09-27 02:33:08 +08:00
sel.setBaseAndExtent(anchor, 0, focus, focus.data.length);
}
}
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
render() {
return (
<div className="participant-profile">
{this._renderProfilePhoto()}
{this._renderCorePersonalInfo()}
{this._renderAdditionalInfo()}
</div>
2017-09-27 02:33:08 +08:00
);
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
}
}