Value Statement

Search team is planning to support event streaming (real-time data) as part of the search API. 

Once implemented, the open websocket will receive ADD / MODIFY / DELETE events from the API. We need to discuss the expectations for the UX around handling these events so the user does not see them as negatively impactful to viewing their search results.

The main issue is our search results table(s) contain pagination. As result items are added / removed from the result tables - how should the event be handled?

Some available options to handle the add/delete events are:

• Manual refresh:
  • Automatically updating tables on MODIFY events
  • Display an alert on screen when add/delete is received, indicating to the user that the search results are stale and need a refresh
• Semi-Manual refresh (like Twitter):
  • MODIFY still auto updates all resources.
  • On page 1, we auto-handle all ADD / DELETE events.
  • On page 2+, we display an alert to inform users data is stale and needs refresh
• CNV VM list page:
  • Add events always append new VM to the end of the table data.
    • On page refresh, the VMs are reloaded and sorted alphabetically
  • Delete from the current or a different tab/window should remove the VM from the table and update pagination counts.
    • This doesn't seem to happen 100% of the time likely due to multiple VM resources not deleting at the same time? Or weird cache?
    • But expectation is that the delete event is automatically handled and the table is updated accordingly.
  • Modify events always auto-update

The main goal of this ticket is to to work with UX team to determine best UX flox for these events and whether Red Hat products already have a solution we should use as well.

Definition of Done for Engineering Story Owner (Checklist)

• ...

Development Complete

• The code is complete.
• Functionality is working.
• Any required downstream Docker file changes are made.

Tests Automated

• [ ] Unit/function tests have been automated and incorporated into the
  build.
• [ ] 100% automated unit/function test coverage for new or changed APIs.

Secure Design

• [ ] Security has been assessed and incorporated into your threat model.

Multidisciplinary Teams Readiness

• [ ] Create an informative documentation issue using the Customer

Portal Doc template that you can access from [The Playbook](

https://docs.google.com/document/d/1YTqpZRH54Bnn4WJ2nZmjaCoiRtqmrc2w6DdQxe_yLZ8/edit#heading=h.9fvyr2rdriby),

and ensure doc acceptance criteria is met.

• Call out this sentence as it's own action:

• [ ] Link the development issue to the doc issue.

Support Readiness

• [ ] The must-gather script has been updated.