Standardize API call handling in frontend

Description

We use redux api middleware so the typical actions are xxx_REQUEST, xxx_SUCCESS and xxx_FAILURE. At the moment we don't have a generic way of handling REQUEST and FAILURE. All the reducers are either ignoring these two or putting it in a particular state and handle it specifically. We might define a middleware to handle these two generically.

See https://github.com/zanata/sync/blob/master/frontend/src/main/web/lib/middleware/apiCallStateChecker.js for example.

Activity

Show:
David Mason
July 12, 2017, 12:35 AM

In general we should be using the information from the request action to show the users that an action is in progress, which will often be specific to an area of the UI (e.g. showing some 'searching' state with a search box).

For failures we should indicate the failure in a specific location when appropriate, and in a more general notification for anything else. If we have a generic notification on all API requests, we need a way to suppress that for the specific cases that we are displaying differently.

Patrick Huang
July 12, 2017, 1:35 AM

We could use the meta field in action. Either to suppress generic handling or to indicate specific location/handling.

David Mason
July 12, 2017, 1:53 AM

Good idea. I think just to suppress generic handling makes most sense, because the specific handling will be bespoke things that can't be done by a notification system (e.g. displaying a loader icon next to a search input).

I can imagine a case where I might want to inspect an error and handle it myself if it is one type of error, but let the notification system handle it otherwise. I guess the simplest thing then would be to suppress the automatic handling, inspect the error, and manually call the notification system with the action if it was not an error I wanted to handle.

Assignee

Unassigned

Reporter

Patrick Huang

Labels

Tested Version/s

None

Components

Priority

unspecified
Configure