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

stream action buttons: Implement search messages in stream #5248

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

SilentCruzer
Copy link
Contributor

closes: #4675

Changes Made:

Video:

search.mp4

Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

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

Thanks @SilentCruzer! Comments below.

In the UI, in this version once you navigate to the screen for searching within the stream, it looks identical to the normal search screen -- there's no visible indication of any kind to make clear that you're doing a search that's specific to one stream.

I feel like there should be such an indication, but I don't have a firm idea of what it should look like. @alya, do you perhaps have a suggestion?

streamId !== undefined
? [
{ operator: 'search', operand: query },
{ operator: 'stream', operand: streamId },
Copy link
Member

Choose a reason for hiding this comment

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

Instead of returning the stream ID here, we should handle it in the same way as in the other two places where we handle operator: 'stream' in this function.

Comment on lines 444 to 445
// Below we are checking if the streamId is mentioned or not
// If it is mentioned, it will construct a narrow based on that.
Copy link
Member

Choose a reason for hiding this comment

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

These two lines are an example of a comment that just repeats what the code already straightforwardly says. So it's better to leave them out and let the code speak for itself.

That's good because it means fewer things to read when seeking to understand the code. It also means one fewer thing that can get out of sync when the code changes, and become wrong -- as is, this sort of comment is highly vulnerable to becoming wrong in the future, and a comment that's wrong is of negative value.

Comment on lines 441 to 443
// The search narrow can behave in two ways,
// one where there is no filters, so the user can search a message in all the streams
// the second where the user wants to search in a particular stream
Copy link
Member

Choose a reason for hiding this comment

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

These three lines are providing potentially helpful context on what we intend for these narrows to mean -- what the meaning is of a search narrow with streamId present or of one with it absent.

The most helpful place for that sort of information to live is on the type definition, instead of down here in the implementation of one of the functions that consumes the narrow. That way, it's in a central place that is natural to refer to whenever someone's trying to understand these objects.

Specifically, let's put it right above the line where you added streamId in the type definition.

Also, it's helpful for documentation like this to be concise. Try and see if you can find a way to express the essential content of what this is saying but in fewer words.

@@ -18,7 +18,7 @@ import { fetchMessages } from '../message/fetchActions';
type OuterProps = $ReadOnly<{|
// These should be passed from React Navigation
navigation: AppNavigationProp<'search-messages'>,
route: RouteProp<'search-messages', void>,
route: RouteProp<'search-messages', {| streamId: number |}>,
Copy link
Member

Choose a reason for hiding this comment

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

This type needs to match up with what's passed to it from navActions. See previous discussion: #5189 (comment)

const searchMessage = ({ streamId }) => {
NavigationService.dispatch(navigateToSearch(streamId));
};
searchMessage.title = 'Search Message';
Copy link
Member

Choose a reason for hiding this comment

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

Let's make this "Search in stream".

Comment on lines 245 to 249
const searchMessage = ({ streamId }) => {
NavigationService.dispatch(navigateToSearch(streamId));
};
searchMessage.title = 'Search Message';
searchMessage.errorMessage = 'Failed to open search';
Copy link
Member

Choose a reason for hiding this comment

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

You'll have a rebase conflict to resolve here, sorry -- see f32a679 for the relevant change.

@SilentCruzer
Copy link
Contributor Author

In the UI, in this version once you navigate to the screen for searching within the stream, it looks identical to the normal search screen -- there's no visible indication of any kind to make clear that you're doing a search that's specific to one stream.

Maybe we can try changing the placeholder text in the search bar. Currently, it simply shows "Search",

image

Say if we are searching in the mobile-team stream, we can use a UI like this:

image

We are already passing the streamId in the SearchMessages component, we can get the stream name using that. The screen component already has the searchPlaceholder as a prop, so we can pass the stream name there.

@gnprice
Copy link
Member

gnprice commented Apr 22, 2022

Maybe we can try changing the placeholder text in the search bar.

Yeah, good idea -- that'd certainly be a good start.

Once the user has typed a query, I'd still worry a bit that it looks like they're getting results for simply the query they typed, when in fact they're getting results for that query plus limiting to the stream. So I think ideally there'd be some other indication, one that stays visible after entering a query.

@alya
Copy link
Collaborator

alya commented Apr 27, 2022

I think we can show stream:foo in the search box, and put the cursor after it for the user to enter the query. That's the approach that we use in the webapp, and it seems reasonable for mobile as well.

Does that sound right? If we do so, deleting the stream:foo part should do a regular search with no stream restriction.

@SilentCruzer
Copy link
Contributor Author

SilentCruzer commented Apr 29, 2022

I think we can show stream:foo in the search box, and put the cursor after it for the user to enter the query. That's the approach that we use in the webapp, and it seems reasonable for mobile as well.

Does that sound right? If we do so, deleting the stream:foo part should do a regular search with no stream restriction.

This seems good to me, For this, we might need to add a feature that allows the regular search bar to recognize the keyword stream: which can be whole another issue, I will try to update this pr with the searching using `stream: feature.

@SilentCruzer
Copy link
Contributor Author

@alya, I have made the suggested changes. Here is the demo of how the search screen looks with new changes:

search.mp4

If the stream: foo is removed, then it behaves like a normal search. But if stream:foo is typed manually in the normal search bar, it does not narrow down the search instead it behaves like the normal one.

I wanted to add the feature where the user can manually type stream:foo and narrow down the search, so I just wanted to be sure of the implementation before I add it. Does it make sense to use the streamAutoComplete component which we use in the chat screen to mention streams for autocompleting the stream names and get the streamId at the same time?

@alya
Copy link
Collaborator

alya commented May 24, 2022

Cool, thanks! We should definitely make sure that stream:foo works, and behaves the same way whether you typed it manually or not.

@chrisbobbe or @gnprice would be in a better position to comment on the implementation question.

@gnprice
Copy link
Member

gnprice commented May 25, 2022

We should definitely make sure that stream:foo works, and behaves the same way whether you typed it manually or not.

@chrisbobbe or @gnprice would be in a better position to comment on the implementation question.

I agree this would be good to have; it's in the tracker as #4903. I think it will be a somewhat bigger project than this PR was: it'll mean we want to start actually parsing the user's input in the search box, as Zulip search syntax.

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.

Add "Search topic" option to topic actionsheet
3 participants