feat(contacts-menu): implement custom javascript hook action

[st3iny]

• Part of: Availability view of other people #44776
• Requires: feat(NcAvatar): implement custom javascript hook action for the contacts menu nextcloud-libraries/nextcloud-vue#6238
• Requires bumping @nextcloud/vue to >= 8.22.0 chore(deps): bump @nextcloud/vue from ^8.20.0 to ^8.22.0 #50074

Summary

Adds a new frontend-only contacts menu action registered via registerContactsMenuAction("foo-bar") from @nextcloud/vue.

Note: Please focus on the contact menu changes when reviewing this PR. The modal you see might change and is part of the Calendar app.

2024-11-27.14-35-29.mp4

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[susnux]

Does it make sense to register this in the backend?

One the one side we already have link actions, but on the other link actions make sense for php-only apps and javascript actions would always need JS code.

Asking because all other APIs we introduced lately for similar things are purely frontend. E.g. file actions, views, filters.
Also older API is frontend only (e.g. user list rows, user actions etc).

[st3iny]

Does it make sense to register this in the backend?

One the one side we already have link actions, but on the other link actions make sense for php-only apps and javascript actions would always need JS code.

Asking because all other APIs we introduced lately for similar things are purely frontend. E.g. file actions, views, filters. Also older API is frontend only (e.g. user list rows, user actions etc).

Hmm, that is actually a good point. But since I'm extending an existing API here, I'd prefer to keep it in the backend for now. Otherwise, it might get confusing as the avatar menu is populated from multiple sources of truth.

I'll think about it again.

[st3iny]

Ferdinand is right. The OCP API doesn't make sense. The menu has to registered from the frontend only, via @nextcloud/vue.

[st3iny]

Unrelated, but my LSP complained that it is illegal to have the same key on the on both nodes of v-if/v-else.

[st3iny]

This PR is now ready and not longer blocked.

[ChristophWurst]

Nitpick deluxe: consider handling async callbacks, to allow actions to signal when they are done. E.g. the screencast at nextcloud/calendar#6502 shows that there is a brief moment of no visual feedback before the modal opens. During that time the action button could switch to a loading state. On a technical level the callback would return a promise, and here you would go into loading state as long as the promise hasn't resolved.

This is not a blocker.

[st3iny]

Good point. This would be a good follow-up.