Better Typescript support for select()!

[yankeeinlondon]

I am using io-ts to provide strong type codec's for all tables in Postgres but in trying to provide better type support for the querying of tables I am running into issues with how types are exposed through @supabase/supabase-js. As a "for instance", let's say I want to provide a type-aware "select" operation for a typescript type/interface called ISong. Let's also assume that this table is represented in Postgres as the "songs" table.

Structurally, the operation would look like this in an untyped world:

const songs = await client.from("songs").select("artist,song").eq("artist", "Jimi Hendrix");

Fortunately you provide the generic on the from() function where you should be able to construct a typed selected operation but the signature of select is inheritantly weakly typed and breaks the chain. Therefore, the following typed structure:

const songs = await client.from<ISong>("songs").select("artist,song").eq("artist", "Jimi Hendrix");

Ideally the above would ensure that within select, only valid column names could be chosen but structurally you're asking for a single comma delimited string and this will never work. You do, however, forward the typing onward to the filter operation so do get strong typing on column name and column's value in the eq(x,y) operation:

Making the select operation type-safe wouldn't be hard and I have worked around it with my wrapper by doing the following:

  return (...columns: TableProps[] | ["*"]) => {
    const cols =
      columns.length === 0 || (columns.length === 1 && columns[0]) === "*"
        ? "*"
        : columns.join(",");

    // receives a _typed_ filter operator which can 
    const filter = client.from<IModel>(tableName).select(cols);

    return filter;
  };

With this in place my wrapper allows me to simply define an io-ts type and then configure supabase like so:

const api = useSupabase(url, token).addTable(Song);

const songs = await api.table.songs.select('artist','song').eq('artist', 'Jimi Hendrix');

Everything in the chain -- including the table name -- is strongly typed. I got around the select's break but it would be nicer if there was a strongly typed way built in. I realize this probably forces a breaking change for your API but maybe there's a way to keep the old means while offering a type-safe option?

[yankeeinlondon]

Note: it would also be very helpful to expose your interfaces -- the implementation is unnecessary -- of elements like PostgrestFilterBuilder on your @supabase/supabase-js named exports. This allows folks to be more explicit in their own type definitions rather than needing to rely on implicit inference.

[stupidawesome]

I'm playing around with this myself at the moment. Implementation here

export const bookingQuery = (id: number) => 
    query("one_time_booking")
        .eq("id", id)
        .return({
            column: ["id", "computed"],
            expand: {
                guest: "guest_profile", // short for guest_profile(*)
                // guest: {
                //    id: "guest_profile",
                //    column: ["id", "avatar_url"],
                //    expand: {
                //        ...etc
                //    }
                // }
            }
        })
        .single()

will produce

data: {
  id,
  computed,
  guest: {
    id,
    ...etc
  }
}

The "select" statement needs to come last so you can filter on props that aren't being returned.

[beeequeue]

I have two PRs open that would improve TS QoL:
supabase/supabase-js#125
supabase/postgrest-js#152
But they are waiting for more info regarding type generation improvements

[kiwicopple]

These are looking pretty good even as they are @beeequeue, but because they are breaking we will want to get as much of the storage updates in before we roll up to 2.0. I completely agree with your postgrest approach - it's much nicer to pass the definitions at init.