Plans for Dynamic clientId Updates?

[zuhno]

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:

1. Using setClientId to change the clientId symbol value.
2. 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.

[kasvith]

Hi @zuhno this is a good suggestion, lets see what we can do here

im initially thinking of providing a method to update the client id value in the provider as you mentioned

[zuhno]

@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?

[kasvith]

sure, go ahead and do a PR, lets review it

[zuhno]

Thanks @kasvith, Opened PR(#61). please review it.

[kasvith]

hi, will do. i got little busy

[splitwarechef]

Is this still in development? It would really be nice to have this feature

[kasvith]

hey guys sorry i was bit occupied with some work

i will get back to it, seems @zuhno 's PR is fine, few final checks and its good to go

im also planning on a re-write with vite 5 and upgrade support for nuxt

[kasvith]

hi @zuhno made few comments on PR, can you check

[zuhno]

hi @kasvith
i've reviewed the comments left on the PR and added responses to them as well. once those responses are resolved, i'll proceed with the improvements right away. for nuxt support of this feature, it should be possible to add it after checking the flow.

[kasvith]

hi @zuhno replied you back

yes we can support this with nuxt also, im however planning to do some migration to latest vite and nuxt with FedCM, will update the main soon