You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 7, 2019. It is now read-only.
This is a feature I'd like to see added, though I could understand if it's too cumbersome or introduces the potential for added bugs.
My server has the ability to provide many raw items in a single call; but the fetcher operates one at a time, so I have to use a different endpoint to get items from the server for one at a time. Not a huge issue but I feel like it's better (and faster) to have one request over multiple requests. I did a quick test and 25 items loaded in 41% of the time via a singular call vs 25 individual calls.
There could be an optional method on fetchers that would be automatically triggered (similarly to the debouncer) For example, if many get calls are called consecutively using different keys, the fetcher will call the multiple fetcher method instead of the singular method for each one.
Or it could have explicit syntax such as getMultiple or fetchMultiple etc.
I understand this could add some complexities and corner cases,
Some items in a multiple fetch may already be cached, meaning there has to be some resolution between those that are cached and those that are being fetched from the network - AND the order must be retained
The server may return some invalid items (i.e. null)
The server may return items in a different order than they were requested. Mine doesn't but that may not be the case for everyone, and a potential source for bugs
What happens when the amount of items returned does not match the amount requested? For example, we request 15 and we get 14 (which one is missing?). Or even worse we get back 16 (which one is extraneous??)
Some of these issues could be resolved by adding another method that allows you to explicitly map a raw item to its key. However that's not something that's in the library at the moment (I assume for good reason)
Sounds complicated :-) I think you hit on some of the instances why. I don't think there's any plans to implement such a feature anytime soon but due to Stores delegating fetching to you, you should be able to make some sort of RequestQueue that can handle multiple calls. As everything you need to weigh abstractions vs speed. Personally, I don't think network calls are ever the cause of app slowness especially since the individual network call time will be amortized over parsing time.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is a feature I'd like to see added, though I could understand if it's too cumbersome or introduces the potential for added bugs.
My server has the ability to provide many raw items in a single call; but the fetcher operates one at a time, so I have to use a different endpoint to get items from the server for one at a time. Not a huge issue but I feel like it's better (and faster) to have one request over multiple requests. I did a quick test and 25 items loaded in 41% of the time via a singular call vs 25 individual calls.
There could be an optional method on fetchers that would be automatically triggered (similarly to the debouncer) For example, if many get calls are called consecutively using different keys, the fetcher will call the multiple fetcher method instead of the singular method for each one.
Or it could have explicit syntax such as
getMultiple
orfetchMultiple
etc.I understand this could add some complexities and corner cases,
Some of these issues could be resolved by adding another method that allows you to explicitly map a raw item to its key. However that's not something that's in the library at the moment (I assume for good reason)
This may be related to #366
The text was updated successfully, but these errors were encountered: