For context: https://github.com/hasura/graphql-engine-mono/pull/6931
This PR makes some revisions that I had originally intended to be in the code, but due to some mixup, was refactored without discussion. @vijayprasanna13 and I synced up to try and make a decision about how to resolve it, but ultimately wanted to get more eyes on it to weigh in.
For context, when I refer to "premade selectors" I am talking about [this file](8a9264b14c/console/src/features/hasura-metadata-api/selectors.ts (L34))
And when I refer to "utility functions" (or metadata utility functions), I am talking about [this file](8a9264b14c/console/src/features/hasura-metadata-api/utils.ts (L38))
The changes I am suggesting here mostly about maintaining (IMHO) clearer separation of concern for selectors vs utility functions, and improving DX.
Here's how I see it high level:
In other words, I want to avoid using pre-made selectors within a custom selector as it creates a pattern of multiple layers of curried functions and beings to (IMHO) look confusing and blur the separation of concern.
What I am proposing is that we have a convention of doing either
1) Developer wants the entire table object of a specific table. They can easily do this using one of the **premade** selectors and pass directly into `useMetdata()`:
```ts
const { isLoading, data: metadataTable } = useMetadata(
MetadataSelectors.findTable(dataSourceName, table)
);
```
2) Developer wants to get a specific piece of information on a specific table. They can leverage the `findMetadataTable()` utility function within a custom inline selector like this and avoid extra currying and double selector confusion:
```ts
const { isLoading, data: savedComment } = useMetadata(
m => MetadataUtils.findMetadataTable(dataSourceName, table, m)?.configuration?.comment
);
```
This is somewhat of a stylistic preference, but also one that I think makes a cleaner separation of concern in the way we are building the api and supportive pieces. In other words, premade selectors are _always_ a selector and not used to compose other selectors. It also makes available utility functions that are easy to pull of the shelf to do common metadata tasks whether in the scope of `useMetadata` or not.
## Simpler Approach?
We could also just go with **Flow # 2** and eliminate the premade selectors. The dev would then pass a custom selector into `useMetadata()` and if they prefer, use a utility function to support their task.
With that aside, whatever the team agrees makes more sense, I will gladly get on board with, but I wanted to make my case here : )
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7095
Co-authored-by: Vijay Prasanna <11921040+vijayprasanna13@users.noreply.github.com>
GitOrigin-RevId: 7ecc2db172def0d2f714cbbb2f95a4b56a528093
The Hasura console is an admin dashboard to manage the connected database and to try out GraphQL APIs. It is a React application bundled with Webpack and the state is managed mostly using Redux.
12d4de57c0
