Which UI do you use?

Custom UI

Pre built UI

Using ProviderInput instead of Provider.init() in the providers list for thirdparty.init

Status

This is just a proposal so far, it hasn't been accepted and needs further discussion.

Status:

proposed

Deciders:

rishabhpoddar, sattvikc

Proposed by:

sattvikc

Created:

2022-10-25

Context and Problem Statement

Currently the providers list in the thirdparty.init() is populated with the providers implementations using the appropriate provider.init() function, such as Google.init(), Facebook.init(), etc.

Instead, should we just accept the thirdparty config as a ProviderInput and then create implementations at runtime?

Proposed init would look like this (2nd option in the considered options):

thirdParty.init({
  signInUpFeature: {
    providers: [
      {
        thirdPartyId: "google",
        config: {
          clients: [
            { clientId: "...", clientSecret: "..." }
          ]
        }
      },
      {
        thirdPartyId: "custom",
        config: {
          clients: [
            { clientId: "...", clientSecret: "..." }
          ],
          authorisationEndpoint: 'custom.com/authorize',
          tokenEndpoint: 'custom.com/token',
        }
      }
    ]
  }
})

Considered Options

• Keep the existing way of using Provider.init()
• Accept ProviderInput instead, with thirdPartyId specified

Decision Outcome

Chosen option: Accept ProviderInput instead, with thirdPartyId specified, because

• Avoids ambiguity in cases like user creating a custom provider with the same id as built-in ones.
• Since the recipes are going to fetch the config from the core, to check if the recipe is enabled, at that point we can merge the provider configs from the core with the statically declared ones, so that within the implementation of the recipe APIs or the providers, we need not do additional steps to fetch config from the core.

Pros and Cons of the Options

Keep the existing way of using Provider.init()

Further details if necessary

Familiar for existing users

Creates ambiguity when user creates a custom provider with same id as built-in provider

Accept ProviderInput instead, with thirdPartyId specified

Provider implementations will be created in runtime, and user will not be able to create ambiguous providers

Enables simplification of the API and provider implementations by doing the config merges before their execution