I use a join table in Supabase to relate ‘users’ to ‘meetings’ and shot myself in the foot with an advanced collection setup without knowing it (because I’m not a coder). This tip is to help you avoid doing that.
In the “Fields” section of a collection configuration you can switch to the “Advanced” tab to have more control of the returned data, including being able to return data from related tables. This is documented in weweb docs.
I read around the forums that you could use the ‘spread’ operator (“…”) to flatten the returned data, making access to the related table data somewhat easier. When using spread, the array of data that is returned has the related table’s information at the same level as the parent table. Without it, the related table data is inside a ‘child’ object.
What I did not realize is when you “spread” data like this, you lose critical info at the highest level, such as the ID of the parent table item.
For example, if you have a join table (“user_meeting”) that assigns ‘users’ to ‘meetings’ by creating an entry in the user_meeting table, and your Data Collection configuration for the user_meeting table is this:
*,...meeting(*)
Then when you later try and locate a specific user_meeting item (to remove a user from a meeting, for example), you will find that the only ‘ID’ you can return from the user_meeting collection is actually that of the meeting itself (the child table) and not the ID of the user_meeting row. Changing the Collection’s configuration to remove the spread operator fixes this:
*,meeting(*)
However, now the meeting data is returned as an object of user_meeting (instead of just placing its data at the base level of the array).
Perhaps this is obvious to coders, but it drove me crazy for a solid day as I tried everything I could to figure out why I couldn’t get the ID of a user_meeting entry out of my collection.
My fault for jumping on an advanced config without really understanding it, but now you know this risk as well and can make a more educated decision on whether to use it.