-
Notifications
You must be signed in to change notification settings - Fork 138
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
chore: merging global error toast with client lib + some refactoring #938
chore: merging global error toast with client lib + some refactoring #938
Conversation
bb526b2
to
991b9c4
Compare
app/graphql/client.tsx
Outdated
@@ -102,7 +129,70 @@ const GaloyClient: React.FC<{ children: React.ReactNode }> = ({ children }) => { | |||
}), | |||
) | |||
|
|||
const splitLink = split( | |||
const errorLink = onError(({ graphQLErrors, networkError: networkErrorRaw }) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has this been tested at all? My concern is that since the error link is executed for each query, if we make multiple queries at the same time, we will see multiple instances of the same toast issue. In the past, it seems the checks for network errors were psuedo-batched by being processed all at once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to make some testing around this.
Where is batching done by the previous code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously the check for errors only ran once after every render with the useEffect
, so if multiple errors came back in between renders it would only run once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how common that is however. Also not sure if the retry logic here will trigger the error link for each retry or just once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so I've tested it locally.
basically from my test: the old code didn't work anymore, or at least even if the server was stopped, there was no error showing up.
with the new code, the toast is showing up. It' not reappearing in an annoying way. if you move screen, it may reappear if you deeper in the flow and are loader new graphql queries that are not watched yet. if you go "back there" is no error message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does setNetworkError
get called to clear the error after a toast has been shown?
991b9c4
to
1533100
Compare
70f79f9
to
71bdd8c
Compare
276f597
to
aa0c9f3
Compare
comment should have been addressed
d6732fc
to
e149342
Compare
7595f13
to
883e4f6
Compare
5c7788a
to
e98de9e
Compare
e98de9e
to
92fda30
Compare
No description provided.