Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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(clerk-js): Add ability to set active organization by slug #3825
feat(clerk-js): Add ability to set active organization by slug #3825
Changes from all commits
7ff078e
7c61adf
3414e6f
3aae4eb
fdb2c08
a9c1051
3483068
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 have two concerns here, borne of my own experience:
1: 🤔 How confident are we that
newSession.user.organizationMemberships
will always present and populated in this case? I don't think you need toawait
anything to get access tosetActive
and call it, so I could imagine a scenario where we haven't yet completed the backend call to/tokens
. But I may be missing something!2: 🤔 Even if we can depend on
newSession
being populated, this smells to me like it's being fed via client piggybacking, and i've heard that we'd rather make API calls for the data that we need explicitly rather than rely on client piggybacking. But again, I maybe misunderstanding something!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'd be happy to pair and trace to find those answers with you @wobsoriano . And I think it's likely that someone with more experience may know the answer to these off-hand - they strike me as foundational-sdk-philosophy questions 😄
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 happened to chat with @BRKalow , and I got my answers!
1: The magic here is that, when someone calls useClerk, they're getting IsomorphicClerk, who'se implementation of setActive is here:
javascript/packages/react/src/isomorphicClerk.ts
Lines 602 to 608 in 427fcde
If clerk hasn't loaded the client by the time the user calls setActive, it'll return
return Promise.reject();
. And if clerk has loaded, we'll have that session data. So this is safe?2: This isn't client piggybacking supplying this data. Client piggybacking is us returning the latest client data on api calls other than the explicit call to load the client, but it's the explicit call that we're making when clerk loads.
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.
This is a good client piggybacking intro. Thanks izaak!