Some frustrations trying to set up Google sheets datasource locally

[Janpot]

• [x] Config errors aren't very actionable. We should split them up and mention the required env vars.

  if (!config.googleSheetsClientId) {
    throw new Error(
      'Google Sheets data source: Missing client ID "TOOLPAD_DATASOURCE_GOOGLESHEETS_CLIENT_ID"',
    );
  }
  // ...

• [ ] We will evolve to a system that doesn't contain sensitive data on the frontend in readable form. Which means that we won't get the value in readable form in the connection editor. We will add the execPrivate method to the input and call a connection test method to determine validity, in the backend it will acquire an access token to check whether the connection works and the user hasn't revoked the token.
• [x] We're going to remove this test function from the interface, it was a bad idea. If a test function is needed we can put it in the connection editor with execPrivate.
• [x] While reviewing implementation I came across this logic where an error is thrown inside of a callback. This will result in uncaught exceptions. Easiest fix is to rewrite this using the promise version of getToken.
• [x] The docs are a bit unclear, I have to resort to google documentation to get there. I would rather explain better the requirements and point to the relevant google documentation to fulfil them. e.g. "You need valid Google Oauth 2.0 credentials". Some useful links:
  • https://developers.google.com/identity/protocols/oauth2/web-server#creatingcred
  • https://cloud.google.com/resource-manager/docs/creating-managing-projects#creating_a_project
  • https://developers.google.com/identity/protocols/oauth2/web-server#enable-apis

[bharatkashyap]

• [ ] We will evolve to a system that doesn't contain sensitive data on the frontend in readable form. Which means that we won't get the value in readable form in the connection editor. We will add the execPrivate method to the input and call a connection test method to determine validity, in the backend it will acquire an access token to check whether the connection works and the user hasn't revoked the token.

Makes sense. Feels like we can convert this one to a separate issue (since removing the value prop from the connection params component is a broader change across datasources)

[Janpot]

We can start by making each datasource not depend on secrets in the ConnectionEditor, we don't necessarily have to do all at once in one PR. The current check for token validity is insufficient as it doesn't check whether the token has been revoked on the user side. We can solve both of these at once, independently of refactoring how datasources work with respect to secrets

[Janpot]

Ordering my thoughts around that in https://github.com/mui/mui-toolpad/issues/403