Develop (3.1.49) #1371
Merged
Develop (3.1.49) #1371
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The module will hold the list of all mods available on Thunderstore API for the current active game, and provide helpers related to that data.
v3.2 brought in some new goodies, although I'm not sure if we can fully utilise them due to old Vue version.
This IndexedDB wrapper is used for storing the responses received when querying Thunderstore API for package listings for a specific game. The refactoring shouldn't be visible to users (except for a minor delay when storing the response) for now. In short term this allows us to drop the duplicate in-memory list of ThunderstoreMod objects. In medium term this aims to make it easier to do further refactorings to deal with the poor performance of handling the very large mod lists in communities like Lethal Company.
The process of accessing the list of mods available via Thunderstore API for a specific game: 1. Components (SplashMixin on the foreground and UtilityMixin on the background) trigger the API request, currently via ConnectionProvider 2. Components pass the response to ThunderstorePackages which writes the results to IndexedDB. ThunderstorePackages module might become obsolete in the future 3. Components trigger Vuex update where TsModsModule reads the mod list from IndexedDB and stores it in memory 4. Component access the list via Vuex To keep the commit size down ModBridge and ThunderstorePackages' internal methods still use the duplicate PACKAGES and PACKAGES_MAP objects, but those will be cleaned out in the subsequent commits.
The methods isn't really used much and this allows us to drop the dependency on the soon obsolete ModBridge.
Implement cached "ManifestV2 to ThunderstoreMod" conversion in TsModsModule in a way that's compatible with what ModBridgre did previously. This allows us to drop ModBridge, and the duplicate in-memory list of PACKAGES.
The old implementation had multiple bugs, and as a result the deprecation status of dependency chains we're not properly checked. Fixing this will cause many mod packs to start showing as deprecated.
After earlier refactorings, the map was used only by the internal methods anymore, so there was no performance benefits to be had by having it stored in memory. Passing the map as an argument makes the code easier to follow, test, and refactor.
Use precalculated deprecation map that takes into account dependency deprecations on LocalModCard. Use the same map on OnlineModView to filter out deprecated mods unless user uses filters to specifically ask for them. And finally use the same map, via Vuex getter, to show the number of mods available online on the navigation sidebar. This works a bit oddly since the filter for deprecated mods is taken into account, but other filters (e.g. NSFW content) are not. However, this is how it worked before the changes too, and further changes are considered outside the current scope.
- Move package exclusions from ThunderstorePackages to TsModsModule - Drop package exclusions altogether from ApiData and ApiCacheUtils. Caching this information on disk doesn't make much sense since the exclusion list is stored in a local MD file anyway. Furthermore, the disk cache file will soon be removed altogether in favor of IndexedDB - Remove references to ThunderstorePackages from SplashMixin and UtilityMixin. Call related methods directly instead. In the future these methods can be combined behing a single Vuex action - Remove now unused package list related methods from ThunderstorePackages
All remaining code deals with calculating the deprecation status of packages based on the status of their dependencies, so the new name is more descriptive. The methods remain wrapped in a class to make it easier to spy on them in Jest test cases.
Reading the value into Vuex is done in the same action as reading the package list in the hopes that they stay in sync. There's nothing to stop someone unknowingly updating the values separately through the mutators though.
This change is required for eventually dropping the API request cached on file in favour of IndexedDB.
The response is now stored on disk by IndexedDB, so having a separate file for this is redundant. This also changes a bit how Splash screens handle the mod list update. The new process is: 1. Request fresh list from Thunderstore API 2. If response was received, store it in IndexedDB 3. Populate Vuex from IndexedDB. If there was no response from the API this step also acts as reading the old values from persistent cache 4. If the mod list was received from API or read from cache, proceed to profile selection; otherwise show the offline mode disclaimer
Update the exclusion list (if not already done), filter the response for excluded packages, and store the rest into IndexedDB in one fell swoop.
First half of the progress is for storing the response to IndexedDB (if a response was received) and the second half for reading the values from database and casting to ThunderstoreMod objects to be stored in Vuex. Add a helper for resetting progress of all subitems on the splash screen.
The error is shown on the UI when manually triggered udpating of the mod list from Thunderstore API fails, so the module which handles all that is more suitable location for managing the error message.
The banner for updating all mods with updates is shown on the view listing the mods in currently selected profile, so the module which handles the rest of the profile related data is a more suitabl location.
The setter already called an async method without waiting for the result. Upcoming changes will add more async calls into the method, so better make it async too.
Changes that moved the mod cache from ModBridge class to Vuex caused the initial rendering of the local mod list take roughly twice as long as before (although subsequent renderings were a bit faster). Since effort has been placed recently to improve the performance, this isn't ideal. One solution to improve the performance is to start prewarming the cache as soon as a profile is selected. This obviously causes a slight performance hit when a larger profile is selected, but overall this is likely less noticeable to the user. Once the cache is warmed, there's no point in resetting the mod list when moving to Manager screen and reloading it there. These changes will make moving to the Manager screen actually faster than it was before (after the cache warming is done), and as a bonus the waiting happens on profile screen, meaning the "no mods here" disclaimer does not flash on screen while the mod list is loaded.
This doesn't affect performance as much as doing the same on the profile selection screen, but is nice for consistency.
When mod disabled status was toggled multiple times while the first change was processed, the files ended up with multiple suffixes. When the mod was then toggled to enabled the files still had the suffix and the mod would now be loaded. The caveat is that any files that actually using .old as file extension will get it ripped off if the mod is disabled and enabled again. While not ideal, I see this as the lesser evil.
- Prevent mod enable/disable toggle starting another process while one is already in progress - Don't disable the input element itself, since this would show a disabled checkbox while the process is in progress, and I don't want to deal with the CSS right now - Make switch ids unique
The lack of type support from Vuex makes this kinda sad though.
Also disable the rename button to indicate it does nothing if a profile with the chosen name already exists.
Add setting for toggling preferred Thunderstore CDN
Update RoRR image and pump settings store schema version
Refactor Delete Profile Modal by separating it from Profiles.vue
Refactor Rename Profile Modal by separating it from Profiles.vue
Add Magicraft
Add the game Another Crab' s Treasure
Add Gladio Mori
Add Slipstream: Rogue Space
TSMM is not ready to release this game yet, but it blocks other changes from being released. I intend to revert this change once TSMM release has been made. (This is not ideal but it's the path of least resistance to get the release done.)
Temporarily hide Risk of Rain Returns from the game list
Revert 833024e (unhide Risk of Rain Returns)
Improve Shimloader tests
TSMM has its own copy of this file, so it's no big deal, but for consistency's sake use relative import path here too.
Change import to use relative path
Hide Risk of Rain Returns until uninstall works as intended
…arsed back from JSON
Changed hasRange to a getter as previous method does not exist when parsed back from JSON
Updated versions and CHANGELOG.md
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.