Major DX change: response and error handling

[thorwebdev]

Decision

We've decided to make a major change to support a better developer experience for working with supabase-js. Instead of throwing an error, we will return the error object as part of the response.

Example

Given a successful query, e.g. const response = await supabase.from('products').select('*'), response will be:

{
  "error": null,
  "data": [...],
  "status": 200,
  "statusCode": 200,
  "statusText": "",
  "body": [...] // for backwards compatibility: `body === data`
}

Given a bad query, e.g. const response = await supabase.from('productx').select('*'), response will be:

{
  "error": {
    "code": 404,
    "message": "relation \"public.productx\" does not exist",
    "details": null,
    "hint": null
  },
  "data": null,
  "status": 404,
  "statusCode": 404,
  "statusText": "",
  "body": null // for backwards compatibility: `body === data`
}

Future DX

This will enable the following experience:

const { error, data: products } = await supabase.from('products').select('*')
if (error) {
  alert(error.message)
  return // abort
}
console.log(`Found ${products.length} products.`)

Additional context

Inspiration has been taken from https://github.com/vercel/swr#quick-start:

import useSWR from 'swr'

function Profile() {
  const { data, error } = useSWR('/api/user', fetcher)

  if (error) return <div>failed to load</div>
  if (!data) return <div>loading...</div>
  return <div>hello {data.name}!</div>
}

as well as Stripe.js : https://stripe.com/docs/js/payment_methods/create_payment_method

[soedirgo]

Does this error handling include programmer errors? Say I pass a list to match where I expect an object, and I use Object.keys on it. Having to handle each and every kind of such exceptions in JS, with the appropriate error messages, is very painful IMO.

For the record, supabase/postgrest-js#93 uses a fetch polyfill for the HTTP client, so there's no need to use the data field in place of body. Currently the error handling looks more like this, though we can shape it to your proposed format:

const { ok, body: products } = await supabase.from('products').select('*')
if (!ok) { // status code is not 2XX
  alert(products.message) // PostgREST's error is stored in body (`T | T[] | PostgrestError`) in case of error
  return // abort
}
console.log(`Found ${products.length} products.`)

[kiwicopple]

Does this error handling include programmer errors?

I don't think this should be expected, just catch and rethrow unexpected errors. As you say, handling every possible error would be unwieldy. We should just shape expected errors.

so there's no need to use the data field in place of body.

This one is just a preference. I guess we should decide now what is the more appropriate name for the key. IMO body seems like a throwback to when we used ajax used to request HTML snippets that would be injected into HTML.

Currently the error handling looks more like this

if (!ok) { // status code is not 2XX
  return // abort
}

I'd far prefer this one to look like the suggested change (if (error)). The term ok is unexpected, and error is very clear

[kiwicopple]

Tasks:

• Update postgrest-js
• Update gotrue-js
• Update realtime-js
• Update supabase-js
  • Install new libs
  • Change the realtime to work with one socket connection per client

Also solves:

• Client & server side method for validating user auth token : Client & server side method for validating user auth token supabase#147
• supabase.auth.logout() throws "Invalid user" error: supabase.auth.logout() throws "Invalid user" error. #15

[stupidawesome]

Are there plans to expose the Content-Range header in the response object?

[soedirgo]

@stupidawesome is there a use case for this? PostgREST supports this, but we haven't really considered having this in. If you just want the COUNT, there's an open issue for it.