WIP: fetch libraryItems within store

[ZachMyers3]

For #762

Moving at least the initial fetch of all items for a given library into the store.

Not sure the best route to go after that, passing all the filters in the library view or somehow pass them back into the store.

[ZachMyers3]

Something I've already ran into...

Hitting local storage limits with this route, probably not the best approach...

[jellyfin-bot]

Cloudflare Pages deployment

Latest commit	6328d99
Status	🔄 Deploying...
Preview URL	Not available
Type	🔀 Preview

View bot logs

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[ZachMyers3]

Moved the userItems to a new store that doesn't use localStorage to hold it. Worked out better anyway, as it can load independent of the other userLibrary data and not cause the entire page to hang on initial load.

Now all objects are being passed on initial load of the page, but that seems to be pretty heavy on the client side rendering all those objects at once. I'm considering lazy-loading the content now that I have all of it.

[ferferga]

@ZachMyers3 First of all, sorry for my delay in answering, I'm full steam on uni atm in the hopes it's the last year.

There are a couple of reasons why this issue has been sitting for a while. All our data fetching and stores related to items need huge refactoring because:

• We're fetching data from the pages directly, which makes us redo a lot of requests and the server APIs are designed in a way that's really unpredictable and one endpoint might return fields that another won't. We can fix this by adding ItemFields to all requests, but that's cumbersome and easily forgotten.
• We need a central place to handle all the items, because we want everything to be reactive. I also tried to hack around this by using the axios interceptors to return reactive copies, but it didn't work and, although we're storing the data, we're always calling server anyway (we can't change that behaviour in the interceptor), so we're not using it for caching at all.
• We also need this central place once in the future we're able to make the client work fully offline, with PWA capabilities.

This also involves thinking and architecting the application in the following fronts:

• Storage: Which storage backend it's the best for this? You already saw some scaling issues with localStorage and sessionStorage. We also want the app to fully work when offline by being a PWA. PWA has it's own caching mechanism (which I didn't had the time to investigate properly yet). Designing a PWA is another feat in itself, since it has it's own set of implications, so doing tests and research in itself it's really difficult. And the PWA ecosystem's status it's actually dubious (though hopefully it improves). So then, which storage backend it's good to be used right now, but can be extended to the PWA ecosystem?.
• Reactivity: We must have a storage backend that can work with Vue's reactivity APIs. Luckily, Vue APIs are tightly integrated into JavaScript, but still have some limitations and they don't work across Workers and Service Workers, for instance. Which brings us back to the PWA question. I've been also toying for quite some time to integrate TanStack query in our application, But, giving a read to their docs, it seems that we can't override the cache storage backend with our own setup, so we can't create a reactive storage wrapper that we can modify using our websocket. We can access QueryCache but we can't write on it, it seems.
• UI/UX: All navigation should be blocked until content is fully loaded (so no content popping). And we should be able to have as fewer loading variables as possible.

Since you landed your PR, I've been tring to give another round in my head and make a plan, so we can get a little bit of the work done. I think this is a good set of baseline requirements:

• Have a IndexedDB store where we can have a real query some more advanced queries.
• We should have a full copy of the server content's in our IndexedDB, which should be fully reactive (with dexie.js we can do that, but maybe there's a better way without externasl deps). The sync would start at user login.
• When a page is accessed, it's data
• All the responses will be mapped to item ids, so we can retrieve data from the reactive database and use it instead. If relevant, data should be updated into the IndexedDB. Even if we can filter data client-side, filtering functions should also query the server, so we display data in a consistent way across all clients.
  • So, for instance, at user login we would start the item sync and the requests for the home page's content. When we have the home page's content, we will map it to ids and query the data that it's already in the database. Once it exists, the promise will resolve, unblocking navigation.
• Use Tanstack query: Although we will only be using it's caching capabilities for request responses and no real data caching, it will be really useful for aborting requests, mutations and other goodies it has.

Hopefully my idea came across clear enough. I understand implementing this at once it's so much, but I think a good baseline for an initial PR would be the database logic, which we can then later apply to the library view. Other stuff will tangle more the mess we're already in, and sadly I won't accept it.

If you're willing to accept this extra work, that this PR might get quite some time without a merge and you have the compromise to do so, I'll be grateful and I'd try to help you along the road as much as I can (even though I can be late in my replies, at least this semester).

[ferferga]

@ZachMyers3 Do you have any interest in keep pursuing this?