return data from Signup() Local Composable

[iamKiNG-Fr]

Describe the feature

The Feature

To allow SignUp() useAuth local composable return data from signup request.

The Journey

I'm unable to get the return data from the Signup request I send. This request contains data that is important for my applications signup process.

This puzzled me for a while after I tried assigning a variable to the signup() sidebase useAuth() function and then log that variable, only to get an undefined value even when i could see the response with the dev tools.

/pages/register.vue
const response = await signUp(credentials, undefined, { preventLoginFlow: true })
console.log(response);
// undefined

chrome dev tool

The Discovery

After further investigation, i noticed that the sidebase nuxt-auth local composable where the signup function is defined actually doesn't return the data from the signup request.

/node_modules/@sidebase/nuxt-auth/dist/runtime/composable/local/useAuth.mjs
const signUp = async (credentials, signInOptions, signUpOptions) => {
  const nuxt = useNuxtApp();
  const { path, method } = useTypedBackendConfig(useRuntimeConfig(), "local").endpoints.signUp;
  await _fetch(nuxt, path, {
    method,
    body: credentials
  });
  if (signUpOptions?.preventLoginFlow) {
    return;  // no data is returned
  }
  return signIn(credentials, signInOptions);
};

you'll notice that when signUpOptions?.preventLoginFlow is true like i have in my code { preventLoginFlow: true } it returns zelch nothing.

And i believe this is the culprit.

How would you implement this?

The Solution

Well I don't know if I'm savvy enough to implement the solution but from what i can see it looks like adding a variable to hold the response from the signup() _fetch request and then returning the variable with the data is the way to go.

for example

/node_modules/@sidebase/nuxt-auth/dist/runtime/composable/local/useAuth.mjs
const signUp = async (credentials, signInOptions, signUpOptions) => {
  const nuxt = useNuxtApp();
  const { path, method } = useTypedBackendConfig(useRuntimeConfig(), "local").endpoints.signUp;
  const response = await _fetch(nuxt, path, {   // added const response to hold fetch data
    method,
    body: credentials
  });
const data = response.json()  // parse the response body
  if (signUpOptions?.preventLoginFlow) {
    return data;   //return the data
  }
  return signIn(credentials, signInOptions);
};

then maybe adjust the accompanying typescript file to reflect the changes to ensure type safety.

Implementation

it'll be cool if i could implement this change under someone's supervision/guidance so i don't break anything, if not that's fine...or maybe there's nothing to fix and i just need someone to help me figure out how i can get this data from the signup function.

Additional information

• [X] Would you be willing to help implement this feature?

Provider

• [ ] AuthJS
• [X] Local
• [ ] Refresh
• [ ] New Provider

[zoey-kaiser]

Hi @iamKiNG-Fr 👋

I agree that it makes sense to enhance and revisit the signUp flow! I saw that your checked the box that you would be willing to help us implement this feature!

As the signUp flow is very isolated from the other parts of authentication, I don't think you need to worry about breaking anything! From my perspective the signUp flow should consist of the following:

• Data is passed to the signUp function
• SignUp request is made with the provided data
• Data from the signUp flow is returned
  • I think we need to also provide a method to type this returned data. Maybe we can re-use the logic from the session.dataType?
  • I think we can also handle the cases where you would like to use this data to conduct further actions by either:
    • Allowing the passing of a callback function
    • Outright returning the data (however, I am unsure if this would conflict with the response of signIn if this function should also be executed, maybe you have some other ideas here?).

[cngJo]

I stumbled across this, trying to catch failing login requests in the refresh provider, which is seemingly not possible atm. At least by awaiting the signIn call.

When there is anything I can help with getting this fixes, I'm happy to help out ;-)

But I like the proposed solution of providing an option to return the response of the fetch call. This would allow for detailed errors messages from the server on failed logins.