You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm currently facing a limitation with the static assignment of the clientId value. My backend server provides redirect_uri and clientId, which I wish to dynamically utilize in my application. However, the current implementation does not allow for changing the clientId symbol value after initialization, leading to inflexibility in adapting to different server responses.
Describe the solution you'd like
I would like the ability to dynamically update the clientId value. Specifically, the solution would involve:
Using setClientId to change the clientId symbol value.
Modifying useOneTap, useTokenClient, useCodeClient hooks to accept clientId as part of the options object, enabling the use of either the initialization value or the dynamically provided clientId.
To implement the above, it would be necessary to optionally accept clientId during app installation.
Describe alternatives you've considered
An alternative could be a more static configuration, but this lacks the flexibility required for different backend responses. I'm open to other suggestions that could provide similar functionality.
Additional context
The inability to dynamically update the clientId hinders the adaptability of the application to different backend environments. Also, there was an issue with the package.json version not being updated, causing a failure in GitHub Action and preventing the NPM version from updating. This is an additional context that might be relevant to the overall functionality and deployment process.
The text was updated successfully, but these errors were encountered:
@kasvith
If we develop using the methods provided by the provider, it seems necessary to verify the initialization of the clientId in the hooks. Having the hooks receive the clientId as an options member would have the advantage of allowing each hook to use a different clientId, though I haven't thought about it in detail yet.
Would it be okay for me to work on it as you suggested and submit a pull request?
Hello :)
Is your feature request related to a problem? Please describe.
I'm currently facing a limitation with the static assignment of the clientId value. My backend server provides redirect_uri and clientId, which I wish to dynamically utilize in my application. However, the current implementation does not allow for changing the clientId symbol value after initialization, leading to inflexibility in adapting to different server responses.
Describe the solution you'd like
I would like the ability to dynamically update the clientId value. Specifically, the solution would involve:
To implement the above, it would be necessary to optionally accept clientId during app installation.
Describe alternatives you've considered
An alternative could be a more static configuration, but this lacks the flexibility required for different backend responses. I'm open to other suggestions that could provide similar functionality.
Additional context
The inability to dynamically update the clientId hinders the adaptability of the application to different backend environments. Also, there was an issue with the package.json version not being updated, causing a failure in GitHub Action and preventing the NPM version from updating. This is an additional context that might be relevant to the overall functionality and deployment process.
The text was updated successfully, but these errors were encountered: