-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify mod list update functionality under Vuex #1597
base: splash-speedrun-pt3
Are you sure you want to change the base?
Conversation
The "background" update originally referred to the periodic updates, i.e. not the update that happens on splash screen and shows the progress to user. The Vuex state is now shared between the background updates and user triggered manual updates that show a lightweight status reporting, so the naming was bit misleading.
As the number of callsites increases, it makes more sense to have the method for downloading the latest mod list, storing it into IndexedDB and loading packages to Vuex inside Vuex, so each component doesn't need to extend the UtilityMixin just to access it. For TSMM this also allows injecting telemetry gathering to the method inside Vuex, and not needing to due it awkwardly in App.vue.
If new mod list was downloaded and stored to IndexDB successfully, but loading the mods to Vuex failed, user would end up in situation where the mod list is empty but it wouldn't be updated until a new version was available in the API. To prevent this, we now always attempt to load the mod list in to Vuex if the the mod list stored there is empty.
The Vuex method now handles preventing multiple simultaneous update calls. It also provides a simple status message for the update process to be shown in the UI when the update process is triggered by the user.
modsLastUpdated: undefined | ||
modsLastUpdated: undefined, | ||
/*** Error shown on UI after mod list refresh fails */ | ||
thunderstoreModListUpdateError: '', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd be worth changing this to be an undefined/Error object. We can do more with the Error itself such as present a modal than we can with just the error message.
if (typeof error === 'string') { | ||
state.thunderstoreModListUpdateError = error; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct me if I'm wrong but this block should never be hit.
We invoke this in one place, and that's part of a try/catch block. We should always hit the instanceof Error
case.
try { | ||
packageListIndex = await dispatch('fetchPackageListIndex'); | ||
} catch { | ||
// "Retry failed after 5 attempts" isn't very helpful error message. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted and agreed, worth removing the comment now as it doesn't benefit the codebase
No description provided.