Emit unified search query

[raimund-schluessler]

This PR emits a global event when the unified search is started or reset. Apps can use this to filter their content.

For the Tasks app this looks like this (with nextcloud/tasks#1202):

A problem might be that the search is not persistent, as soon as the unified search input is closed, the filtering is reset. But this is by design of the search input, so I guess there is not much to do.

[skjnldsv]

Thanks for taking care of this! 🚀
See comments :)

[skjnldsv]

A problem might be that the search is not persistent, as soon as the unified search input is closed, the filtering is reset

Let's address that in a followup, nice catch!

[georgehrke]

@raimund-schluessler Looks like you committed the js files in dev mode. Please compile in production mode.

[raimund-schluessler]

@skjnldsv I now wonder whether we should better watch query instead of emitting in the methods. Something like this

watch: {
	query(query, oldQuery) {
		if (query !== oldQuery) {
			debounce(() => {
				emit('nextcloud:unified-search', { query: this.query })
			}, 200)
		}
	},
},

We would be sure to really catch every change of query, even if it will be changed somewhere else in the future.

[raimund-schluessler]

@raimund-schluessler Looks like you committed the js files in dev mode. Please compile in production mode.

Hm, I don't often contribute to server, sorry. I will try to fix this.

[skjnldsv]

We would be sure to really catch every change of query, even if it will be changed somewhere else in the future.

Well, we are catching any query change. You cannot change it from the outside (not sure we should).
And the only way to trigger it a second time with the same query would be to write some letters and erase them as fast as the current debounce. I'd like to stay clean and avoid watchers as this is not needed.

Unless you encountered some performance/usability issues, but I didn't :)

[raimund-schluessler]

Unless you encountered some performance/usability issues, but I didn't :)

No, usability wise, I think it is ok. I just wondered whether it would be cleaner to only emit at a single place instead of in different methods. But I am fine either way.

[raimund-schluessler]

I think I fixed it. However, the Node build fails, and I don't know why. It tells me there are uncommited changes. I also see them when I run npm run build locally, but I thought they are unrelated to my changes. Should I also commit them?

[skjnldsv]

/compile amend /

[skjnldsv]

I think I fixed it. However, the Node build fails, and I don't know why. It tells me there are uncommited changes. I also see them when I run npm run build locally, but I thought they are unrelated to my changes. Should I also commit them?

Yes, maybe master have an issue 🤷

[faily-bot]

🤖 beep boop beep 🤖

Here are the logs for the failed build:

Status of 32553: failure

acceptance-header

• tests/acceptance/features/header.feature:31

Show full log

  Scenario: users from other groups are not seen in the contacts menu when autocompletion is restricted within the same group # /drone/src/tests/acceptance/features/header.feature:31
    Given I am logged in as the admin                                                                                         # LoginPageContext::iAmLoggedInAsTheAdmin()
    And I visit the settings page                                                                                             # SettingsMenuContext::iVisitTheSettingsPage()
    And I open the "Sharing" section of the "Administration" group                                                            # AppNavigationContext::iOpenTheSectionOf()
    And I enable restricting username autocompletion to groups                                                                # SettingsContext::iEnableRestrictingUsernameAutocompletionToGroups()
    And I see that username autocompletion is restricted to groups                                                            # SettingsContext::iSeeThatUsernameAutocompletionIsRestrictedToGroups()
    When I open the Contacts menu                                                                                             # ContactsMenuContext::iOpenTheContactsMenu()
    Then I see that the Contacts menu is shown                                                                                # ContactsMenuContext::iSeeThatTheContactsMenuIsShown()
    And I see that the contact "user0" in the Contacts menu is not shown                                                      # ContactsMenuContext::iSeeThatTheContactInTheContactsMenuIsNotShown()
      Failed asserting that true is false.
    And I see that the contact "admin" in the Contacts menu is not shown                                                      # ContactsMenuContext::iSeeThatTheContactInTheContactsMenuIsNotShown()

[raimund-schluessler]

I think I fixed it. However, the Node build fails, and I don't know why. It tells me there are uncommited changes. I also see them when I run npm run build locally, but I thought they are unrelated to my changes. Should I also commit them?

Yes, maybe master have an issue 🤷

So, I should commit all files which are generated by npm run build? Or is it alright now?

Edit: I guess compile amend fixed it.