(master) Error handling for (failing) backend end calls

SAP / spartacus

Spartacus is a lean, Angular-based JavaScript storefront for SAP Commerce Cloud that communicates exclusively through the Commerce REST API.

Apache License 2.0

740 stars 384 forks source link

(master) Error handling for (failing) backend end calls #7349

Open tobi-or-not-tobi opened 4 years ago

tobi-or-not-tobi commented 4 years ago

There are a number of issues with the current effect implementation.

effects are not exposed in the public API
effects are complex to understand
errors are often "swallowed" and can't be traced as a developer or end user
methods are often private which blocks extensibility
logic is sometimes written in the constructor, which cannot be customised

What we should do:

storing errors in store, so they can be traced or we can create an event handler for it
handling error events
refactor effects so the code is better readable and extensible.

This occurs through all effects, so we'd start with an exemplary effect to demonstrate the shape of the new effects. Therefor we should balans an example that is not too complex. Products could be a good one to start with. Carts are more urgent, but also very complex.

tobi-or-not-tobi commented 4 years ago

Currently we're generating the error payload in a generic without proper error types. The errors are generally inconsistent in the backend, which is why the code in Spartacus isn't optimised.

Since this error handling in the effects isn't exposed, other libs or customers would ideally reuse our approach.

Pucek9 commented 3 years ago

IMO it could have some structure like { key/code/type: 'uniqueErrorIdentifier', context: 'idOfRequestedItem', message: 'description'} I don't remember exactly, do we have some cases where context was about more than 1 item (otherwise context can be an object with properties pointing to them)

If backend returns only property message which is not translated, it's mostly useless (still nice to have it for developer perspective - it's more clean than code/type to describe problem, helpful for prepare e.g. translations) and we must parse it by RegExp or use request data.

Platonn commented 3 years ago

An example of this type of regexp mentioned by @Pucek9 can be found here: https://github.com/SAP/spartacus/blob/65310b29dfb3d4d984b4585a57a47bf2dc5f996c/feature-libs/organization/administration/core/http-interceptors/conflict/conflict.handler.ts#L17-L20