-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: dynamic clientId Initialization #61
base: main
Are you sure you want to change the base?
Conversation
Thanks @zuhno this is a brilliant work, and im really happy about this PR 💪 it looks really good as i checked on surface |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
im going through the code little bit
@kasvith Please let me know if there are any parts that need to be revised. |
Sure, i didnt have much time lately to focus on the project |
src/composables/useTokenClient.ts
Outdated
const isReady = ref(false); | ||
let client: TokenClient | undefined; | ||
|
||
const login = (overrideConfig?: OverridableTokenClientConfig) => { | ||
if (!isReady.value) { | ||
if (!clientId?.value) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems we are repeating this in multiple places, can we perhaps extract it to a composable? like useClientId
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would useClientId
be a hook intended solely for internal use within the library? If it’s not meant to be exposed externally, I think it might also make sense to modularize the validation part within the login
function as a utility function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think for now it can be used internally
yes, refactoring validation part would be nice too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
completed the refactoring.
please review the code, and let me know if any further adjustments are needed 😀
src/utils/validations.ts
Outdated
@@ -0,0 +1,22 @@ | |||
import { toPluginError } from "./logs"; | |||
|
|||
export const validateLoginSetup = (isReady: boolean, clientId?: string) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shall we call it isClientIdValid ?
also lets get rid of the nested if statements and use early returns
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as you mentioned, we can use an early return. in doing so, the throw new Error
would become non-executing code, so if there's no need to throw an error, using early return could be a good approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can throw error as early return
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
applied early return, which allowed me to improve the nested if statements
refactor: applied early return to 'isClientIdValid'
Hi :)
setGoogleClientId
, which operates by changing the global ref value.GoogleSignInButton
is called.I am very happy to contribute to this project. Please let me know if there are any suggestions for improvements in the folder structure or functionality.