https://supertokens.com/ logo
Join DiscordCommunities
Powered by
<@498057949541826571> Since my application needs t...
# share-your-work
i
@rp_st Since my application needs to update 
supertokens-node
to latest, I'm probably going to update the example Remix/SvelteKit repos to work with the latest version. Are there any other incoming breaking changes that I should be aware of before migrating those examples to the latest version?
Seems you're away. If you're okay with it, I'm hoping I can leave some questions here regarding migrations. 1) It looks like 
EmailPassword.getUserByEmail
is deprecated. So I'd have to use 
SuperTokens.listUsersByAccountInfo
. Would that look like this?
Copy code
ts
import SuperTokens from "supertokens-node";
const users = await SuperTokens.listUsersByAccountInfo("public", { email: "email@example.com" });
if (users.length === 0) // User does not exist ...
My main concern is if I should be importing from 
supertokens-node
or something else like 
supertokens-node/build
. Does it matter? Also is this performant? 😅 I would think it would be preferable to get just one user at a time, no? Or is this related to multi-tenancy?
^Related to this 
listUsersByAccountInfo
deal. If I'm just using a regular 
EmailPassword
recipe, is there any chance that the array returned to me will be larger than 1? I guess the real question is... In what scenarios will this list return me more than 1 users for a single email?
--- 2) Is there a reason to prefer 
EmailPassword.sendEmail
over 
EmailPassword.sendPasswordResetLink
or vice versa?
--- 3) Will 
EmailPassword.sendEmail
ever support the new verification link option?
--- 4) What's the difference between 
consumePasswordResetToken
and 
resetPasswordUsingToken
? (Or rather, why would I use 
consume
instead?)
I'm out of time for today. I will do some more migration later this week (and potentially add new questions to this thread). Hopefully it won't be too difficult.
r
1. Yup. You are right. You should never import from 
/build
path. Also, it is performant. We have an index on the email. > If I'm just using a regular EmailPassword recipe, is there any chance that the array returned to me will be larger than 1? it would be 0 or 1. > Is there a reason to prefer EmailPassword.sendEmail over EmailPassword.sendPasswordResetLink or vice versa? One reason you may want to use sendEmail is cause it allows you to customise the link however you like before calling the function. Otherwise, it doesn't matter. > Will EmailPassword.sendEmail ever support the new verification link option? You mean email verification? Thats a different recipe. > What's the difference between consumePasswordResetToken and resetPasswordUsingToken? (Or rather, why would I use consume instead?) consumePasswordResetToken just checks if the code is OK and deletes it from the db. The other function calls consumePasswordResetToken, and if it's OK, then also calls the change in the user's password.
i
Thank you!
Okay. Another question. From the docs (https://supertokens.com/docs/session/common-customizations/sessions/new-session#createnewsession-without-req--res-dependency), I saw this in the example code:
Copy code
ts
    let userId = "userId"; // get from db
    let session = await Session.createNewSessionWithoutRequestResponse("public", supertokens.convertToRecipeUserId(userId));
Currently, my 
signup
helper looks something like this:
Copy code
ts
const helpers = {
  // ... Other Helpers ...
  async signup(email: string, password: string): Promise<SignUpResult> {
    const signupResult = await EmailPassword.signUp(tenantId, email, password);
    if (signupResult.status === "EMAIL_ALREADY_EXISTS_ERROR") return { status: signupResult.status };

    const { status, user } = signupResult;
    const session = await Session.createNewSessionWithoutRequestResponse(user.id);
    return { status, tokens: session.getAllSessionTokensDangerously() };
  }
}
Do I need to change 
user.id
to 
SuperTokens.convertToRecipeUserId(user.id)
? And will I need to do this in every situation where I get the 
user
as a result of calling a method on the 
EmailPassword
recipe? I still haven't gotten to study what the new 
RecipeUserId
means yet and wrap my head around it. I'm still working through the Changelog.
r
Right. If it doesn’t give you a type error, you are good to go
i
Perfect
Another question. 😅 Is the 
user
object safe to use in all other parts of a web application? I only need to use 
RecipeUserId
when doing specific things like creating sessions?
r
Yup!
i
It seems this is the input to 
EmailPassword.sendEmail
now:
Copy code
ts
export declare type TypeEmailPasswordPasswordResetEmailDeliveryInput = {
    type: "PASSWORD_RESET";
    user: {
        id: string;
        recipeUserId: RecipeUserId | undefined;
        email: string;
    };
    passwordResetLink: string;
    tenantId: string;
};
Are there specific circumstances where the 
RecipeUserId
is required? Or is it always optional?
(Hopefully that will be my last question for a while. I can start doing manual testing after this.)
r
right, it is that way cause during account linking, we want to sometimes create a new email password user (so there is no recipe UserId), for an existing user (for example an existing google login user). In that case, the user ID will point to the google loginmethods's userID,and recipeUserId is undefined.
i
Ahhhhhh, okay. So when it's possible to supply the value, I should supply it.
r
yup!
it's not used by us internally anyway, but it's always good to supply it cause the type allows it
PreviousNext
Powered by