-
-
Notifications
You must be signed in to change notification settings - Fork 655
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On message touch, do a narrow #333
Conversation
Automated message from Dropbox CLA bot @borisyankov, it looks like you've already signed the Dropbox CLA. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
key={item.id} | ||
auth={auth} | ||
messageId={item.id} | ||
message={item} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this simplification!
Can not reproduce. |
You're right. I must have gotten into some weird state :) I think this diff needs a bit of a manual rebase against master because there have been some changes that git won't catch. For example, |
@@ -59,16 +59,11 @@ export default ({ auth, subscriptions, messages, narrow, mute, doNarrow }) => { | |||
list.push( | |||
<MessageContainer | |||
type="message" | |||
id={item.id} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also need to change MessageList
to look at props.message.id
instead of props.id
when generating its list of 'anchor' messages (otherwise scrolling gets messed up)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
Implements zulip#306
Fixed the email issue too. |
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written, for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)".
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written, for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)".
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written, for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)".
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written, for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)".
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written, for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)".
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written (as `getNarrowFromMessage`), for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)". Co-authored-by: Chris Bobbe <cbobbe@zulip.com>
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written (as `getNarrowFromMessage`), for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)". Co-authored-by: Chris Bobbe <cbobbe@zulip.com>
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written, for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)".
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written (as `getNarrowFromMessage`), for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)". Co-authored-by: Chris Bobbe <cbobbe@zulip.com>
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written, for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)".
There's no reason we would sometimes want a stream narrow here. This is just how it was when this function was first written (as `getNarrowFromMessage`), for narrowing to a message's conversation, in 34ab1f9 (zulip#333) in 2017. This case also should be impossible anyway, because message topics should always be nonempty -- we convert empty to "(no topic)". Co-authored-by: Chris Bobbe <cbobbe@zulip.com>
Implements #306