Pokemon in storage

[bLangved]

What this issue is about:

Solution so that the user do not have to fetch all/selected pokemon (and generations) each time user wants to check

To-do's

• [ ] Store pokemon generations in local/session storage upon fetch
• [ ] Create statements in fetch to check for entries in storage, and retrieve that instead of fetching again

Considerations

1. Using LocalStorage:

   • Pros: Minimizes API calls significantly, enhances user experience by speeding up load times on repeat visits.
   • Cons: Risk of serving outdated data if the API updates. Requires a mechanism to clear or update cached data.

2. Using SessionStorage:

   • Pros: Reduces API calls within a session, provides more up-to-date data across different sessions.
   • Cons: Data is fetched again in each new session, which might be more frequent than necessary for data that doesn't change often.

3. Hybrid Approach:

   • You can also consider a hybrid approach where you use LocalStorage but implement a mechanism to check for updates in the API. For example, you could store a timestamp or a version number along with the data and periodically check if this version is still current. If the API provides a way to query the last update time or version, you can use this to decide whether to fetch new data or use the cached data.

Relevant project paths

src/js/ src/js/fetchData

[bLangved]

@RiverMichael Dataene i API'en er altfor store for å bruke sessionStorage eller localStorage (maks data på rundt 10mb). Hver pokémon request tar omtrent 0.25mb, så en generasjon er fort en plass mellom 30-50mb. Går ann å bruke løsninger som "IndexedDB", som kan holde mye større mengder data, samt komprimere data på vei inn, og dekomprimere data når det trengs igjen, men dette har ikke jeg satt meg inn i.

Midlertidig løsning: Bruke pagination for å begrense hvor mange requests som gjøres ved hver pokemon generasjon, og man heller kan scrolle / klikke på en knapp for å hente mer.