Update Type Implementation (supabase-js side)

[beeequeue]

What kind of change does this PR introduce?

A breaking type update, which allows easier and stricter type checking. This is a combined update for this package and postgrest-js.

supabase/postgrest-js#152

It also updates the next-ts example application!

What is the current behavior?

• You have to pass the object you're working on into .from<definitions['user']>('users') every time you use it.
• .select() does not have any intellisense help.

What is the new behavior?

You get intellisense suggestions in .select().

---

You now pass the schema into the SupabaseClient, and let the types handle the rest from there.

The schema type is based on what openapi-typescript generates, as recommended in the guide (which also has to be updated as the tool has renamed).

type User = {
  username: string
  data: object | null
  age_range: string | null
  status: 'ONLINE' | 'OFFLINE'
  catchphrase: 'string' | null
}

type Schema = {
  users: User
}

const supabase = new SupabaseClient<definitions>(REST_URL)

// Incorrect table, column names will result in type errors
typedClient.from('users').select('username').eq('username', 'supabot')

// Error
typedClient.from('uesrs').select('username').eq('username', 'wooo')
typedClient.from('users').select('username').eq('not_in_table', 'wooo')

Additional context

Not passing in a type still works as before, with any names working and returning any.

I tried very hard to not make this a breaking change, by still allowing .from<Object>(), but it's sadly impossible without some crazy workarounds. 😢

[beeequeue]

Not sure what happned here, I just installed a package with the latest npm@6 version...

[beeequeue]

Added an example type generation script, along with the package to generate it with

[kiwicopple]

I like the direction of this @beeequeue .

My first hesitation is on the open-api generated definitions. Although we added it to the docs, I have found them a bit limited. For example the swagger that it generates seems to have incorrect types (strings for dates), and it doesn't handle edge-cases like default fields not being required.

I started thinking that we can generate these ourselves by connecting directly to the database. I documented some of this in our CLI RFC here: supabase/cli#2

As soon as we decide what we will do for the Type generators I will loop back here - I think this ultimately is the correct way to handle types, rather than on every select()

[beeequeue]

I would be very glad to help out with type generation!

A custom generator came to mind for me as well, especially since I've been thinking about how Supabase's API kind of resembles GraphQL a lot, with schemas and how you access them. It should be possible to create a client that uses a normalized object store like the Apollo Client or Urql's Graphcache.

{
  "queries": {
    "user.filter(username='supabot')": [
       "User:3126db5b-6371-430a-9342-3dd28997bc2a",
       "User:6b2f2d5b-2a61-4ceb-9258-1cf21e4f65c5",
    ]
  },
  "objects": {
    "User:6b2f2d5b-2a61-4ceb-9258-1cf21e4f65c5": {
      "id": "6b2f2d5b-2a61-4ceb-9258-1cf21e4f65c5",
      "username": "supabot",
    }
  }
}

I've been thinking that it could be fun to try to implement and would be a lot easier with more information about the schema than can be gotten from the Swagger documentation!

[sannajammeh]

What happens when you introduce advanced joins etc? There needs to be a way to override. Same with the .eq operator when joining another table. Where is this IntelliSense going to come from with the suggested type updates?

[beeequeue]

Guess I can close these now.