Skip to content
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

Merged
merged 1 commit into from
Feb 15, 2017
Merged

Conversation

borisyankov
Copy link
Contributor

Implements #306

@smarx
Copy link

smarx commented Feb 14, 2017

Automated message from Dropbox CLA bot

@borisyankov, it looks like you've already signed the Dropbox CLA. Thanks!

Copy link
Member

@neerajwahi neerajwahi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get exceptions when I run this in the simulator and click on a message:

screen shot 2017-02-14 at 11 34 28 pm

key={item.id}
auth={auth}
messageId={item.id}
message={item}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this simplification!

@borisyankov
Copy link
Contributor Author

Can not reproduce.
Also, likely not connected to this PR.

@neerajwahi
Copy link
Member

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, doNarrow takes a second parameter with the message to show initially when narrowing (so that clicking on a message header doesn't jump to the latest message in the narrow).

@@ -59,16 +59,11 @@ export default ({ auth, subscriptions, messages, narrow, mute, doNarrow }) => {
list.push(
<MessageContainer
type="message"
id={item.id}
Copy link
Member

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@borisyankov
Copy link
Contributor Author

Fixed the email issue too.

@borisyankov borisyankov merged commit 34ab1f9 into zulip:master Feb 15, 2017
@borisyankov borisyankov deleted the fix306 branch February 21, 2017 20:49
gnprice added a commit to gnprice/zulip-mobile that referenced this pull request Feb 5, 2020
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)".
gnprice added a commit to gnprice/zulip-mobile that referenced this pull request Feb 6, 2020
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)".
gnprice added a commit to gnprice/zulip-mobile that referenced this pull request Feb 6, 2020
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)".
gnprice added a commit to gnprice/zulip-mobile that referenced this pull request Feb 6, 2020
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)".
gnprice added a commit to gnprice/zulip-mobile that referenced this pull request Feb 6, 2020
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)".
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this pull request Nov 25, 2020
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>
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this pull request Dec 5, 2020
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>
gnprice added a commit to gnprice/zulip-mobile that referenced this pull request Dec 8, 2020
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)".
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this pull request Dec 8, 2020
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>
gnprice added a commit to gnprice/zulip-mobile that referenced this pull request Dec 8, 2020
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)".
gnprice added a commit to chrisbobbe/zulip-mobile that referenced this pull request Dec 9, 2020
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants