Skip to content
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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

Conversation

zuhno
Copy link
Contributor

@zuhno zuhno commented Jan 2, 2024

Hi :)

  1. Added folders for methods, constants, and states (for global ref) under src, and restructured the folder architecture considering scalability for future method development.
  2. Introduced a new method named setGoogleClientId, which operates by changing the global ref value.
  3. The clientId can be initialized in the following ways:
  • Statically during middleware installation.
  • Dynamically in any component.
  • Initially set and later updated dynamically.
  1. Fixed an issue where the style height value was not being applied to the element before the renderButton of GoogleSignInButton is called.
  2. Updated the documentation, including a caution block in the section about initializing nuxt-vue3-google-signin.

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.

@kasvith
Copy link
Collaborator

kasvith commented Jan 2, 2024

Thanks @zuhno

this is a brilliant work, and im really happy about this PR 💪
i will review the code and let you know my thoughts :)

it looks really good as i checked on surface

@kasvith kasvith self-requested a review January 2, 2024 16:06
@kasvith kasvith marked this pull request as draft January 2, 2024 16:06
@kasvith kasvith changed the title Enhancement: Dynamic clientId Initialization feat/Dynamic clientId Initialization Jan 2, 2024
@kasvith kasvith added the enhancement New feature or request label Jan 2, 2024
@kasvith kasvith marked this pull request as ready for review January 2, 2024 16:07
@zuhno zuhno mentioned this pull request Jan 15, 2024
Copy link
Collaborator

@kasvith kasvith left a 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

@zuhno
Copy link
Contributor Author

zuhno commented Apr 26, 2024

@kasvith Please let me know if there are any parts that need to be revised.

@kasvith
Copy link
Collaborator

kasvith commented Jun 17, 2024

Sure, i didnt have much time lately to focus on the project

@kasvith kasvith changed the title feat/Dynamic clientId Initialization feat: dynamic clientId Initialization Jun 17, 2024
const isReady = ref(false);
let client: TokenClient | undefined;

const login = (overrideConfig?: OverridableTokenClientConfig) => {
if (!isReady.value) {
if (!clientId?.value) {
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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

Copy link
Contributor Author

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 😀

@kasvith kasvith self-requested a review October 31, 2024 15:38
@@ -0,0 +1,22 @@
import { toPluginError } from "./logs";

export const validateLoginSetup = (isReady: boolean, clientId?: string) => {
Copy link
Collaborator

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

Copy link
Contributor Author

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.

Copy link
Collaborator

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

Copy link
Contributor Author

@zuhno zuhno Oct 31, 2024

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'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants