mirror of
https://github.com/supabase/supabase.git
synced 2026-10-13 21:29:08 +03:00
There is a bug in the Table Editor mobile view: 1. Open the Table Editor in mobile. 2. Open a tab with a table. 3. Use the Table Editor Menu to switch schemas. This switches the schema in the URL and in local storage, but the Table Editor Menu closes immediately and you can't see the list of tables in the new schema to pick. 4. Open the Table Editor Menu again to pick a new table. The schema automatically flips back to the previous schema, and the Table Editor Menu only flickers open temporarily before closing again. There is no way to access the tables for your newly selected schema. The cause of the bug: There is a useEffect that triggers every time the Table Editor Menu is opened in mobile. (It technically has selectedTable?.schema in its dependency array, but since the menu unmounts and remounts on visibility toggle, the effect runs regardless of whether global selectedTable state has changed. That's also why desktop works fine, because the menu is continuously mounted in desktop view.) When the useEffect runs, it sets the schema to the schema of the currently selected table. Therefore, what actually happens: 1. Schema is set to `schema_a`. The currently selected table is `schema_a.table_a`. 2. User changes schema to `schema_b`. 3. User reopens Table Editor Menu. useEffect runs. Currently selected table is `schema_a.table_a`, so the schema automatically changes back to `schema_a`. Menu automatically closes. The fix: The actual behavior on desktop right now is probably what we want: - The selected table is only used to set the schema if no explicit schema is provided. - If an explicit schema is provided, the user probably chose it, so we allow the schema to not match the currently selected table. The table tabs update to include the table schema anyway if the schema changes, so it should be somewhat obvious that the schema of the menu and the selected table don't match. Therefore, the logic we want is `!!selectedTable?.schema && !selectedSchema`. Because of this change, we can also take it out of the useEffect, which means less circular logic. that Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Writing components
Where to create your components
- For components that declare the general structure and layout of a page:
/components/layouts/xxx
- For components that are tightly coupled to a specific interface:
/components/interfaces/xxx
- For components that are meant to be reusable across multiple pages:
/components/ui/xxx
- Note: We're gradually moving files out of the
to-be-cleanedfolder into the respective folders as we refactor
Component structure
- If a component has constants and utility methods that are tightly coupled to itself, keep them close to the component and enclose them in a folder with an
index.tsxas an entry point - Otherwise it can just be a file on its own
- For example:
-
components/ui - SampleComponentA - SampleComponentA.tsx - SampleComponentA.constants.ts - SampleComponentA.utils.ts - SampleComponentA.types.ts - index.ts - SampleComponentB.tsx
-
Template for building components
// Declare the prop types of your component
interface ComponentAProps {
sampleProp: string
}
// Name your component accordingly
const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}
export default ComponentA