When the additional attributes are finished loading and being rendered to the stats table, as a performance optimisation, the entire table is replaced with the newly built table. This causes issues when updating values or changing the state of the table element. For example when changing training schedule, assigning the player to the line or among substitutes.
If the user changes the training schedule before the data is loaded, the following table replacement will overwrite changes done by the user (no training schedule will be selected and he is forced to reselect it again).
Proposed solutions
Replace only the cells with the loadded additional attributes - performance might be worse.
Before replacing entire table, check for changes in the cells and apply them before or after replacing.
Do not allow any changes to be made before the additional attributes are loaded.
Loading mechanism updates
When the data needs cache revalidation, it can take a considerable amount of time to do the process for multiple players, especially with slow internet connection.
This can delay entire process of additional attributes loading.
First, show the data with existing cached values and then update the data if they differ in value after the revalidation.
This way the data is displayed almost immediately.
This can help to fix the issue described above. Show cached data (this is expected to be a quick process, making it less prone state override), revalidate if needed and update the cells only if the value has changed.
If the number of players stored in the storage is high, it can delay the initial cached values retrieval, therefore implement a mechanism to clean up the storage.
Create a new repeating task and remove players, which do not exist or are retired.
Also consider removing players not in any of my teams (the data is not used anywhere anymore, but AI trend could be shown in the player profile).
Instead of repeatedly retrieving the cached players (see PlayerHelper.js:332:
const cachedPlayer = (await PlayerHelper.cachedPlayers(storage)).find((player) => player.id === playerId);
and finding the specific player by ID with find()
Cache the players list differently. Instead of an array of objects, use an array of objects where the key is the player's ID. This way the player data can be accessed faster and with more direct approach.
Cache the list in the PlayerHelper's property once during the initialisation.
If a new player is being requested, continue as usual, once the parsing is complete, update the player in the storage as well as in the cached property (probably not needed, because there is no scenario, where the same player is requested twice on the same page).
Fix: Entire table is replaced when data is loaded
When the additional attributes are finished loading and being rendered to the stats table, as a performance optimisation, the entire table is replaced with the newly built table. This causes issues when updating values or changing the state of the table element. For example when changing training schedule, assigning the player to the line or among substitutes. If the user changes the training schedule before the data is loaded, the following table replacement will overwrite changes done by the user (no training schedule will be selected and he is forced to reselect it again).
Proposed solutions
Loading mechanism updates
When the data needs cache revalidation, it can take a considerable amount of time to do the process for multiple players, especially with slow internet connection. This can delay entire process of additional attributes loading.
Proposed solutions
Investigate if
<template>could be used https://developer.mozilla.org/en-US/docs/Web/HTML/Element/templateFirst, show the data with existing cached values and then update the data if they differ in value after the revalidation.
If the number of players stored in the storage is high, it can delay the initial cached values retrieval, therefore implement a mechanism to clean up the storage.
Instead of repeatedly retrieving the cached players (see
PlayerHelper.js:332:const cachedPlayer = (await PlayerHelper.cachedPlayers(storage)).find((player) => player.id === playerId);find()as well as in the cached property(probably not needed, because there is no scenario, where the same player is requested twice on the same page).