Functional overview
This story concentrates all the discussions arount the general "real-time update" feature the team had during estimation of the stories.
Technical overview
Edit in place
Given that the "Edit in place" interaction really is an "artifact update" in a general sense, we must be able to handle realtime events for the general case of "artifact updates".
We will introduce the realtime message-sending mechanism here.
We need to send realtime events for taskboard from the Tracker plugin (where the PUT /artifacts/:id route lives). Tracker will send an event (Dispatchable) that the taskboard plugin will listen to. It will then need to detect whether the artifact is used in one or many taskboards. Finally, it will send realtime messages to all the identified taskboard "rooms" to notify front-ends that the card has been edited.
If the "mapped list field" for a card is changed, we will need to send two events:
- An event for removing the card from its current cell.
- An event for adding a card to a new cell.
This strategy is easier than handling every case of "update" events.
Front-end for Realtime edit in place
In order to have a nice UX for change of "mapped list field" value, we will maintain a cache of "hot cards". Whenever we receive a "removed from cell" realtime event , we will store the card in this cache and hide it from the view.
When we receive an "added to cell" realtime event, if we find the card in the cache, we can retrieve the card from the cache and display it in the new cell. Meanwhile, we will query the taskboard_cards/:id REST route to update the card (potentially, every field has changed as well as the "mapped list field"). When the route answers, we erase the card from the cache and re-draw it from the REST payload.
We will need an animation to have a seamless transition between the two realtime events so that people don't wonder "what is happening ?"
Drag and drop
Reminder of the realtime events:
2 events are emitted:
- one to remove the card from the cell
- one to add the card into the new cell
The "add" event should tell us "before" or "after" which artifact id the new card is in the cell. We should not try to reuse global "rank" which is computed in backend, as it is computed dynamically.
When the add event is received, taskboard app should re-query the card to get the complete and up to date data. The fetch of the card can be done with the existing route GET /taskboard_cards/:id. Given that there may be trigger rules between parent and child, the app should also re-query the parent of that card (its remaining effort may now be 0).
When the card is removed, it needs to be placed in a "cache of hot elements" to avoid having to re-query everything to display it again.
Reordering of cards
When reordering cards, we need to have a sensible behaviour. For example, with permissions on artefacts, we might receive a "reorder" event from Realtime "before" or "after" an artifact id that we are not allowed to see. In these cases, we should put the card at the "end" (bottom) of the cell.
- What should be the UX of realtime addition of addition/removal/re-order of parent items (stories)
- esp. I'm on my way to drop a card into a given cell but someone is re-ordering the stories so instead of dropping into "Story A", I ended dropping into "Story B".