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:

Former user 12 July 2017 at 01:53

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.

Former user 12 July 2017 at 01:35

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

Former user 12 July 2017 at 00:35

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.

Details

Assignee

Reporter

Labels

Tested Version/s

Components

Priority

More fields

Created 15 June 2017 at 01:27
Updated 12 July 2017 at 01:53