[24.0] Fix Multi-History status bar reactivity #17812
Conversation
|
After some investigation, properly implementing status updates in the multi-history requires bigger changes and, at this point, it is starting to feel more like a feature request than a bug. We need to watch (poll) every history in the multiview to track the changes and I think we don't have an equivalent endpoint to As a bug fix, I think we should probably disable any operation (except for the multi-selection) to any other history that is not current. What do you think? |
We would still be able to move items from/to histories in this view, right? You mean we would just disable the content item operations such as deleting etc? |
Exactly, that is my proposition. It should work for moving items from/to histories because we reload the history unconditionally after the operation. I'm still trying to fix issues with reactivity though, the |
davelopez
force-pushed
the
24.0_fix_multi_history_counts
branch
from
58c4bb9 to
cd25d16
Compare
|
remilestoned to 24.1 (otherwise it's blocking 24.0) |
|
Yes, I'm still struggling with this one... it may take some time to get fixed |
|
The only missing part of the puzzle now is how to make the
I would appreciate someone having a look and seeing what might be missing or wrong with it. |
The current history details will be loaded by the history watcher anyway.
Technically this model is used by the "client API" in the old controllers so the current API is not using it, but it is useful to have the schema in the client to know what we are getting when requesting something from the server.
This will make the history data available for all the app and reduce duplicated requests.
This should give us an idea of what information is being stored and retrieved each time.
And avoid reactivity issues with lost references
Add composables to deal with "extended" versions of histories when needed. Use proper types for history references in components.
To use AnyHistory type and userOwnsHistory function
This allows to request only those fields that might have changed after an operation in the history contents.
I don't like this at all, but we don't have a way to deal with those operations in a multi-view scenario. This should be a temporary fix util we work on enabling real multi-history support both in backend and client.
davelopez
force-pushed
the
24.0_fix_multi_history_counts
branch
from
592731a to
6b46650
Compare
Let's do this on dev, after we evaluate what to improve.
To accurately reflect what the server is serializing for each different view or usual request from the client.
… this is much cleaner in vue3...
|
It's working now as expected! 🎉
|
| const { wrapper, axiosMock } = await setUpWrapper(UserHistoriesMock, count, currentHistoryId); | ||
| const wrapper = await setUpWrapper(count, currentHistoryId); | ||
|
|
||
| console.log(wrapper.html()); |
There was a problem hiding this comment.
absolutely... 😅 Thanks!
🦅 👁️ 😄
Fixes reactivity issues related to the
HistoryCounter,DefaultOperations, and the History store.Adds stronger typing to history-related components, especially the HistoryStore, to clarify which information is being stored and retrieved when dealing with histories. This includes a new schema model
HistoryDevDetailedused by the "client controller API" and adds more missing fields. Although our FastAPI endpoints do not use this model, it contains the information we are working with when requesting history details in the UI and it's slightly different from theHistoryDetailedmodel.TODO
Isolate the target history from the "current history" when operating on histories in the multi-view.We cannot really do this without creating or modifying endpoints to support multi-histories and "monitor" the state of those.devby fully supporting multi-histories (see first point).How to test the changes?
(Select all options that apply)
License