useLoader on its own is fine but there is a growing set of issues in both how R3F and Three loaders work.
I dont have time to resolve this for v10.0 but think it could be a good 10.1 or whatever minor feature so this issue acts as a catch all and discussion platform.
known ideas/issues:
- Better Caching
- Global/Single Abort
- Persistence. Using WebFS or LocalStorage assets could be set to persist beyond the browser request cache.
- Custom Cache Keys: (issue)
Right now urls are treated as the key for the cache, if you load an asset like before login, then login and the system passes a token to all fetch requests, this is treated as a new URL and thus loads a different version. If we could set the key different from the request we could do this different.
- Cache via Workers [Krispy PR] Moving some parts of requests to workers or interacting with requests made in workers.
This will be much harder because Three loaders use xhr requests to be able to do things like progress. Workers and the Cache API use Fetch.
- Cache Visibility: the Cache is a bit of a black box
- Queue and Progress: Tools like useProgress work by tapping the DefaultLoadingManager and the onProgress event/handler. Issue is, async queries confuse counts and the progress events only fire on a single response at a time. So you get a progress bar that goes 0-100 over and over. Unreliable progress: Assets like GLTF may call additional remote resources, so the total size of a request cant 100% be known, but We could do a few different things to try and get the size of the asset prior to the loading call ( content-length in HEAD, single byte GET and content-range, etc)
Even without pure size we can have each request in a queue and know what percentage of requests are pending, failed, finished, etc.
This is a draft for now, I'll keep working on this and I'm hoping to hear other ideas/feedback
useLoader on its own is fine but there is a growing set of issues in both how R3F and Three loaders work.
I dont have time to resolve this for v10.0 but think it could be a good 10.1 or whatever minor feature so this issue acts as a catch all and discussion platform.
known ideas/issues:
Right now urls are treated as the key for the cache, if you load an asset like before login, then login and the system passes a token to all fetch requests, this is treated as a new URL and thus loads a different version. If we could set the key different from the request we could do this different.
This will be much harder because Three loaders use xhr requests to be able to do things like progress. Workers and the Cache API use Fetch.
Even without pure size we can have each request in a queue and know what percentage of requests are pending, failed, finished, etc.
This is a draft for now, I'll keep working on this and I'm hoping to hear other ideas/feedback