Supabase Plugin - Integrate Supabase into your Bubble app

Thank you so much @Nass, it’s game changer!

1 Like

Hi, @Nass

I am following the latest update of the Supabase plugin for Bubble, but I am still on version 1.31.0. I have a question about best practices when using reusable elements, especially in a Single Page Application (SPA), which is my preferred development style in Bubble.

I noticed that when using the “supabase Auth” element more than once on the same page (especially within reusable elements), it can initialize multiple times and duplicate actions like login. To avoid this, I started using properties to share data between reusables, keeping only one “supabase Auth” on the main page, which seems to solve the issue.

My question is: in scenarios where a reusable inside another needs to, for example, execute a logout action, would it be acceptable to use more than one “supabase Auth” on the same page? In this specific case, I had to add another “supabase Auth” inside a reusable to log out the user, as this reusable didn’t have direct access to the main page’s “supabase Auth”. This resulted in the “supabase Auth” being loaded twice. Is the best practice to always keep only one “supabase Auth” per page, or are there situations where using more than one is recommended?

I used the Container a lot, as I often utilize multiple reusable elements inside other reusable elements, since I work with a Single Page Application (SPA) format. This made it easy to fetch data through the Container, as I only needed to place it once without having to make the call again.

With the removal of the Container in version V2, what do you recommend as best practices to replace it? Should I create a reusable element similar to the example you demonstrated in this link https://supabase-editor.bubbleapps.io/version-test/structuring_app, where I can place the reusable element multiple times (i.e., in several reusable elements) but ensure that it only fetches data in the reusable element that is currently visible?

What I mean is, when using the Supabase plugin by Nocodegarden, it becomes challenging to program in Single Page Application (SPA). Since you developed the app, what would be the best approach? Would it be more efficient to avoid using SPA and switch to separate pages, ensuring that each data fetch only happens once per page? Or is it fine to have multiple reusable elements on the same page, each with the “Supabase Database” element performing the same fetch but in different contexts?

In cases where multiple reusable elements need the same data fetch, would you recommend distributing those elements across different pages to avoid duplicated fetches? Or could SPA still be viable with an optimized approach, ensuring that each “Supabase Database” only runs when necessary?

Hi @arturdiboa
Thank you for your message.

I noticed that when using the “supabase Auth” element more than once on the same page (especially within reusable elements), it can initialize multiple times and duplicate actions like login.

To clarify, there is always a single Supabase client regardless of how many auth components are on your page. What’s happening is that the events and states are propagated through all the auth components (resulting in duplicate logs), but there is only one call to Supabase.


in scenarios where a reusable inside another needs to, for example, execute a logout action, would it be acceptable to use more than one “supabase Auth” on the same page? In this specific case, I had to add another “supabase Auth” inside a reusable to log out the user, as this reusable didn’t have direct access to the main page’s “supabase Auth”. This resulted in the “supabase Auth” being loaded twice. Is the best practice to always keep only one “supabase Auth” per page, or are there situations where using more than one is recommended?

If I understand correctly, you are describing this scenario:

reusable 1
   includes auth component
   includes reusable 2
      needs to call auth.logout()

In that case, having an auth component in reusable 2 is totally fine. You can call then call action on either of the auth components (login, logout, etc…)


Should I create a reusable element similar to the example you demonstrated in this link https://supabase-editor.bubbleapps.io/version-test/structuring_app, where I can place the reusable element multiple times (i.e., in several reusable elements) but ensure that it only fetches data in the reusable element that is currently visible?

Yes, you can definitely define a reusable component for each of your tables. Each reusable would expose the Fetch action as a custom event and the objects state as a custom state.

If you have an SPA and would like to keep previous data (to avoid having to fetch again when displaying the data), here’s an example setup:

Let’s say you have a Todos table in Supabase, and on your SPA you want to display two lists:

  • RG1: list of all todos
  • RG2: list of todos related to the current user

You can define two reusables:

  • reusable.ListTodos (Objects state will contains all todos)
  • reusable.listTodosUser (Objects state will contains todos relative to the current user)

then:

  • RG1 datasource is set to reusable.ListTodos
  • RG2 datasource is set to reusable.listTodosUser

You won’t need to re-fetch data since you’ll have a reusable containing the data for each context.


To save resources on your SPA, you can also:

  • Call “Unsubscribe from realtime” when your data is not visible
  • Call “Subscribe to realtime” when your data is visible again

This could also be declared as custom events (Unsubscribe/Subscribe) on your reusable.

I hope this helps! Feel free to send me a DM if you need more details on this setup.
Best!

Hi,
The complete changelog for version 2.0.0 and later is now available:

The documentation and demo will be updated in the next few days!
Best!

Hi @Nass I think there is a bug with “Reset a Supabase Uploader”. When I use it to only reset the component states, if there is a file it removes it from storage bucket.

Hey @lorenzodelia125,
I just ran some tests, and it looks like the files aren’t being removed from the bucket. What version of the plugin are you using?

I’m using 2.0.5. In the image below there is a test I did. With “Load files” I load into the Supabase Uploader previously uploaded images (to see them in the preview and be able to perform operations) and then (just for testing) I reset the Uploader states with “Reset a Supabase Uploader”. So “Reset” action removes the image from the bucket. This also happens using Reset in other workflows.

Thanks for the details, I was able to reproduce the same behavior.

Could you clarify what exactly you’d like to achieve? Would you prefer to only reset the states (status code, status message, files, last file, etc.) while keeping the loaded files visible in the uploader?

Yes! The ideal situation, in my opinion, would be for the “Reset” action to return the Uploader states to their initial state, including the files loaded to the Uploader via the “Load files” action (as if the “Load files” action had not been used), but without removing the file from the bucket storage, since for that there is the “Remove” action I think.

Can i interrupt (sorry) with a quick question. I have a lambda function triggered by a xlsx file appearing in a bucket. This file is used to upsert records in Supabase. However, I need to know when the updates have completed. I know I can use the ‘table updated’ event to listen for changes, but does it react to every change (if I’m adding 100 records, for example)? Is there a way to know when they are all finished?

I’ll send you a DM, as I’m still a bit unsure about your needs. I’d love to fully understand them before making any changes to the plugin. Thanks!

Hey @kimbern
No worries! Yes it will be triggered for every change.

Maybe the easiest way to handle that would be to have a separate status table. You could update a specific column in that table once all the upserts are completed.

Then, you can subscribe to Realtime updates on this table to get notified when the whole process is done.

Thanks @Nass. I never even thought of that. So simple. Spent a month trying to send an xlsx file directly to an api call (lambda function) in Bubble, just so I could know when the operation had completed! Trying to correctly decode a base64 xlsx file after receiving it encoded from Bubble was turning into a dead-end for me. This is much easier (so long as one of the file uploader plugins can send an xlsx file to an aws s3 bucket without corrupting it)

1 Like

Hi @Nass,

I have recently started using the plugin and I am facing difficulties to setup database component properly.

Please find the details I have added in DB component

This is screenshot of debugger mode

Please guide me, Thanks!

found the solution, needed to expose public schema in settings>api

Hey @ankit2
Perfect. You can even remove “graphql_public” from the Exposed schema if you don’t plan to use it.

1 Like

Hi, @Nass

I’m encountering an unexpected behavior when using the SupabaseAuth element in Bubble, related to the global logout flow and session management. I’ll explain how to reproduce the issue:

  1. The user is logged in on two different browsers.
  2. When I perform a global logout on one of the browsers, all user sessions on all devices are correctly terminated.
  3. In the browser where the global logout was not initiated, the plugin still retains cached information, indicating that the user is still logged in.
  4. If I refresh the page in this browser, the plugin attempts to perform an automatic login but returns the error auth-session-missing in the SupabaseAuth A Call Error event.
  5. When this error occurs, I am unable to execute any action with the user, such as logout, because the auth-session-missing error persists.

To work around this issue, I implemented an automatic refresh flow when I detect the user-not-found or auth-session-missing errors. This makes the plugin recognize that the session no longer exists and logs the user out correctly.

However, when performing the refresh, a new error occurs: invalid-refresh-token-refresh-token-not-found, indicating that the refresh token could not be found. Despite this, the unexpected behavior is resolved, and the user can perform actions normally after the refresh.

Question:

What would be the best flow to handle these two scenarios? Have you observed this behavior when performing a global logout before? Is there any recommendation or adjustment to the flow of actions that could prevent these issues?

Thank you for your attention and for the excellent work on developing the plugin!

Hey @arturdiboa
Thanks for your message. I’ll run some tests on my own and get back to you this week.
Best!

1 Like