Handle error and deal with UI in cozy-client ?

[Crash--]

Let's say we have an application uploading a few files. This application will use Cozy-Client and specially FileCollection.createFile() to upload the file.

Currently, cozy-stack returns an HTTP error 413 if the cozy is out of free space and cozy-client throws this error. That mean that, in my application I need to do something like :

try {
  const upload = await filecollection.createFile()
} catch(error){
  if(error.status === 413){
    showModal(<QuotaAlert />
  }
}

It works well if we have only one application handling the upload, we'll though about this case and implement it. But this is not the case anymore. We have several apps or libs that deal with uploading files, and we need to implement this logic everywhere.

We should mutualize this work and be sure, that even if the application doesn't handle the 413 error, we still display this QuotaAlert.

Should we create a way to catch cozy-client exception in a plugin and instantiate this plugin in the cozy-client Provider ? Something like:

Provider

constructor(){
  //...
  client.registerPlugin(ExceptionsPlugin);
}

ExceptionPlugin:

import {showModal, QuotaAlert} from 'cozy-ui'

class ExceptionPlugin {

constructor(client){
  client.on('exception', this.handleException)
}

handleException = (e) => {
  if(e.status === 413){
    showModal(<QuotaAlert />)
  }
}

[ptbrowne]

I fully agree, we should have generic errors handled automatically.

I am not sure a plugin should be used here as it is not made for React, a plugin does not live inside the React tree. A component could fit the job here I think.

const CozyProvider = props => (
  <Provider>
    { props.children }
    <ClientErrors client={client} />
  </Provider>
)

[Crash--]

How this ClientErrors can listen an exception if there is no plugin dispatching the event? What do you have in mind?

[edas]

I'm not fond of having a generic exception plugin that catch all 413 requests. As I see it, UI response should be dealt by UI components, not by dev APIs.

May we add this to the weekly meeting tomorow ?

[ptbrowne]

How this ClientErrors can listen an exception if there is no plugin dispatching the event? What do you have in mind?

cozyClient would emit "exception" events and ClientErrors would start listening to this event in its componentDidMount.

[ptbrowne]

As I see it, UI response should be dealt by UI components, not by dev APIs.

If I understand well, you propose that the QuotaAlert component be explicitly shown to the user : the app dev should think of the upload failure and show it if there is an error.

What I see as an advantage:

• Forces us to not to be sloppy and prepare for client-side errors
• We can see all places where a QuotaAlert can appear fairly easily
• No QuotaAlert modal could show up unexpectedly
• We do not need a new API to tell cozy-client to ignore potential errors when an API error that normally triggers a UI should be ignored

Inconvenients:

• Can forgot some places to handle errors. Could be prevented by static analysis ? Typescript ?
• App must know about generic errors

An alternative would be :

• Explicit handling of the error by the dev via a method from cozy-client...
• That would show a generic UI

const handleClientError = err => isQuotaAlert(err) && showQuotaAlert(err)

try {
  client.doUpload()
} catch (e) {
  handleClientError(e)
}

• More explicit: I personally see this as an advantage, I am not too fond of a magic modal appearing
• No need to deal with generic errors for apps++

[edas]

We could even have a

import { quotaErrorUi, errorsUi } from 'cozy-client'

const managedErrors = [ quotaErrorUi ]

try {
  client.doUpload()
} catch (e) {
  if (! errorsUI(e, managedErrors ) ) {
    // errors not manager by one of our default handlers
  } 
}

errorsUI will do what you suggest (check if this is a quota error and launch the quota modal if so).

This way we could define a lot of handlers in cozy-client, but still have them pushed explicitly, and letting the caller define their own or opt-out for what they want.