Custom fetch per request

[enyo]

Feature request

When using the load function in Svelte Kit, it provides a fetch implementation that can be used.

From the official docs:

SvelteKit's load receives an implementation of fetch, which has the following special properties:

• it has access to cookies on the server
• it can make requests against the app's own endpoints without issuing an HTTP call
• it makes a copy of the response when you use it, and then sends it embedded in the initial page load for hydration

Describe the solution you'd like

I think that it would be necessary to specify the fetch on a "per request" basis. Something like this:

supabase.withFetch(fetch).from('mytable').select();

Full example:

<script context="module">
  export const prerender = true;
  import { supabase } from "$lib/initSupabase";

  export async function load({ params, fetch, session, stuff }) {
    let { data, error } = await supabase.from("users").select();

    if (error) {
      return {
        status: 500,
      };
    } else {
      return {
        props: {
          users: data,
        },
      };
    }
  }
</script>

Describe alternatives you've considered

Maybe I'm overthinking this. The way I've solved this so far is by creating a function:

export const getSupabase = (fetch) => createClient(url, anonKey, { fetch });

I then use it in my load function.

Is there a downside in creating multiple clients like this? If not, this issue can probably be closed.

[soedirgo]

Not sure about Auth and Realtime, but for REST this should be fine.

Alternatively (and this is a bit hacky):

// initSupabase.js
let currentFetch;

export function setFetch(fetch) { // call this per request
  currentFetch = fetch;
}

export const supabase = createClient(..., { fetch: (...args) => currentFetch(...args) });

[w3b6x9]

I don't think this will impact Realtime.

[soedirgo]

There shouldn't be an issue with using multiple clients, so closing this.

[5hee75]

There shouldn't be an issue with using multiple clients, so closing this.

@soedirgo I have definitely encountered an issue with multiple clients, specifically when using auth listeners. I created a client factory, similar to OP, where each request to the SDK would create a new client. I did this so I could inject dynamic headers and settings into the client for each execution.

const supa = (...params) => createClient(...params);

supa().from...
supa().auth...
// etc

The issue I found was that auth listeners/events are registered to a specific client instance, not to the auth events themselves. I'm not sure if this is intended or not.

So in my example above, if I do this:

const supa = () => createClient(...);

supa().auth.onAuthStateChange((event, session) => {
  if (event === 'SIGNED_OUT') {
    console.log('Auth Event', event);
  }
});

supa().auth.signOut();

The listener is never called, presumably because I signed out from a different client instance. The auth token and user details are still removed from localStorage though.

[enyo]

Oh man @5hee75 I was wondering forever why this happened in my app. This explains it perfectly.