Unify common frontend implementation for emoji reactions between Work Items and Design Management
Summary
Work Items support emoji reactions both at the root object (#393599 (closed) & !119585 (merged)) as well as in discussions (#389967 (closed) & !115972 (merged)). We recently added support for emoji reactions to design discussions too (#29756 (closed) & !125740 (merged)).
All these instances of emoji reactions use awardEmojiAdd, awardEmojiRemove, or awardEmojiToggle mutations. These mutations can work with awardableId which can accept GraphQL Global ID of any awardable reference and requires the user to be logged in to use it.
The frontend implementation uses vue_shared/components/awards_list.vue to show emoji reactions already added by users (along with optionally showing emoji/components/picker.vue is used.
The components where repeating logic is present on the frontend are;
work_items/components/work_item_award_emoji.vuework_items/components/notes/work_item_note_awards_list.vuedesign_management/components/design_notes/design_note.vue
Additionally, there may be other places too where logic is duplicated, like handling mutation response and writing Apollo cache with correct object structure, and paginating emoji list when reactions are more than 100.
Proposal
We need to find a way to unify frontend logic in some way, some of the approaches I can think of are;
- Create a wrapper for
vue_shared/components/awards_list.vuethat can accept permissions for visibility of adding reactions and awardableId and return mutation response that the parent component can consume to write Apollo cache as per its needs, this wrapper should also be able to handle pagination. - Create a wrapper for
emoji/components/picker.vuesimilar to above, pagination is not applicable here.