-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
chore: refetch chart data on pull down to refresh #29661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
841559b
53ed368
91b9fd0
4f1a30d
c3da206
2f0f9bd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -37,6 +37,8 @@ export interface UseOHLCVChartResult { | |
| nextCursor: string | null; | ||
| /** True if the API returned an empty data array (asset not supported for OHLCV) */ | ||
| hasEmptyData: boolean; | ||
| /** Force a re-fetch of the initial data (e.g. on pull-to-refresh). */ | ||
| refetch: () => void; | ||
| } | ||
|
|
||
| const mapCandle = (candle: OHLCVApiCandle): OHLCVBar => ({ | ||
|
|
@@ -148,5 +150,13 @@ export const useOHLCVChart = ({ | |
| return () => abortRef.current?.abort(); | ||
| }, [loadInitial]); | ||
|
|
||
| return { ohlcvData, isLoading, error, hasMore, nextCursor, hasEmptyData }; | ||
| return { | ||
| ohlcvData, | ||
| isLoading, | ||
| error, | ||
| hasMore, | ||
| nextCursor, | ||
| hasEmptyData, | ||
| refetch: loadInitial, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. future - we can refactor to use tanstack query, has built in refetch mechanisms
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmmm debating if we want to move to tanstack now actually. That way we can remove the refreshCounter logic and the state nice and clean. Places that want to perform a refresh can easily invoke our hook and call the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with the broader vision, we have talked about this today; this comment here on a previous PR explains at a high level the alternative approach;
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thinking that perhaps even with tanstack we would still need the counter logic 👀
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah right it wont be needed actually.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The 7.76.0 will be out to users tomorrow, we should be able to have it at 100% to users by next week then we can remove feature flag safely?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm good call out. If this critical/needs to be cherry-picked, then happy to get this merged and we can plan a refactor. If not critical, then I don't mind we wait until a cleanup. I'll try to propose a tanstack approach for this (refreshing can be done by the built in refresh mechanic, or by queryCache invalidation)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think this is a sev1. We can wait for a proper fix with tanstack once we clean up the FF. The idea is to have all entry points that land on Token Details use tanstack query to cache security data; instead of passing it through nav params where shape mismatches can silently break things (which is exactly what's happening with the swap token selector today). Token Details would then own its own data: check the query cache first, fetch on-demand if it's not there. On pull-to-refresh, we just call queryClient.invalidateQueries() for the relevant query key.. tanstack handles the refetch, deduplication, and cache update automatically. No counter approach needed.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Amaaazing, sorry to block this. If you feel like this does need to get in later, then happy to get merged and resolve as a fast follow.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not at all, good callout, if we block it now, this means less cleanup for later; unless someone reports this as a sev1, let's keep it open for now, and fix it properly with FF cleanup |
||
| }; | ||
| }; | ||
Uh oh!
There was an error while loading. Please reload this page.