ToolCards are displayed inside ListCards in three different views:
Of these, only MyLists is reactive to the removal of tools from the menu that is accessible from the ToolCard toolbar. In the other two views, the ToolCard of the removed tool remains inside the List unless the page is reloaded.
Of these, only MyLists is reactive to the removal of tools from the menu that is accessible from the ToolCard toolbar.
Except that removing tools using the menu is no longer working in the MyLists view either. Not only is it not reactive –– it's not working at all. Currently investigating what caused this regression.
Except that removing tools using the menu is no longer working in the MyLists view either. Not only is it not reactive –– it's not working at all. Currently investigating what caused this regression.
Not sure what to make of this. Rebuilding my docker containers and volumes from scratch "fixed" the problem. Either my dev environment was actually "corrupted", or this is like @Raymond_Ndibe's bug from earlier this week that was only reproducible under certain circumstances.
The reason why the MyLists view is reactive to the removal of a tool from a list using the ToolMenu is by happy coincidence rather than design. Both ToolMenu and MyLists use the myLists Vuex state directly, so the MyLists view is inherently reactive to changes in Vuex myLists triggered by ToolMenu.
As for the PublishedLists view and the Lists component used on Home, ToolMenu doesn't have any direct (or indirect via e.g. props) connection to the lists rendered in these views.
I'm not yet sure of the most elegant way to watch for list changes triggered by ToolMenu in the other views that aren't MyLists.
If I'm understanding the problem you would like any mounted ListCard.vue or ListInfo.vue instance to be notified when ToolMenu.vue is used to change the groups a tool is associated with.
Currently the action on ToolMenu.vue triggers a call to the lists/editList vuex action and then on success fires lists/getMyLists which gives you the side effect of reactivity in MyLists.vue as that component is driven by the same lists.myLists state that is updated by lists/getMyLists. You could leverage the same activity, an update to the lists.myLists vuex state as the trigger to refresh other components by mapping that state into the component and then setting a watch on it for changes. When the change event for lists.myLists fires you could then either naively refresh the list that the component is displaying or you could be a bit more conservative of network resources and first check to see if that list is contained in lists.myLists and only update in that case.
This is basically an event bus pattern leveraging the shared state of vuex as the event source rather than a dedicated bus.
Change 781624 had a related patch set uploaded (by Slavina Stefanova; author: Slavina Stefanova):
[wikimedia/toolhub@main] ui: Fix reactivity issues when deleting lists through the ToolMenu
Change 781624 merged by jenkins-bot:
[wikimedia/toolhub@main] ui: Fix reactivity issues when deleting lists through the ToolMenu
Change 786342 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):
[operations/deployment-charts@master] toolhub: Bump container version to 2022-04-21-215651-production
Change 786342 merged by jenkins-bot:
[operations/deployment-charts@master] toolhub: Bump container version to 2022-04-21-215651-production