auto init apiClient and support handle error globally

[baurine]

resolve #738

What did:

• Auto init API client
• Add the mechanism to enable the API request to choose to handle the error by itself or globally, default is global

An example:

[breezewish]

Good!

[baurine]

Hi @breeswish , addressed the comments, PTAL, thanks!

[breezewish]

How about omitting errorStrategy: ErrorStrategy.Custom for all useClientRequests, since errors are already extracted to an object field called error? There might be very little cases for GET requests that want some Modal / Message instead of an Error bar

[baurine]

How about omitting errorStrategy: ErrorStrategy.Custom for all useClientRequests, since errors are already extracted to an object field called error? There might be very little cases for GET requests that want some Modal / Message instead of an Error bar

So it means we should always pass errorStrategy: ErrorStrategy.Custom to request inside the useClientRequest, right? like this:

      const reqConfig: ReqConfig = {
        cancelToken: cancelTokenSource.current.token,
        errorStrategy: ErrorStrategy.Custom,
      }
      const resp = await reqFactory(reqConfig)

I count all the references for useClientRequest, now there are 15 references that don't handle the error by itself, so now if they meet error, it will display the error by notification. The other 9 references handle the error by its self, show error by ErrorBar or Alert.

Should we change all the useClientRequest to handle error by itself?

By the way, we should tidy all the cases how they handle the error by this chance.

[breezewish]

@baurine Yes, exactly. For your referenced these 15 useClientRequests maybe an error bar is a better place, to be unified with the rest (just a guess. worse to be analyzed case by case). For example, for an InstanceSelect, the error bar can be displayed inside the drop content, instead of just prompting a message. Prompting a message is not helpful for user to know where the error comes from.

We'd better to change all useClientRequest caller to handle the error returned by useClientRequest, i.e. finding some suitable place to reflect the error.

[baurine]

@baurine Yes, exactly. For your referenced these 15 useClientRequests maybe an error bar is a better place, to be unified with the rest (just a guess. worse to be analyzed case by case). For example, for an InstanceSelect, the error bar can be displayed inside the drop content, instead of just prompting a message. Prompting a message is not helpful for user to know where the error comes from.

We'd better to change all useClientRequest caller to handle the error returned by useClientRequest, i.e. finding some suitable place to reflect the error.

Ok, Got it!

[baurine]

Tidy all the API requests.

[breezewish]

Cool, mostly LGTM

[baurine]

All kinds of errors:

• GET:

• POST:

[baurine]

All addressed, @breeswish , PTAL, thanks!