Client Side Page Transitions

[HaNdTriX]

Your question

Why is next-auth not using Next.js client page transitions?

In Detail

next-auth currently implements page transition using window.location= <newURL>.
It uses this technique on login and on logout. I understand that on first oauth redirect request this doesn't make a difference, but on all other cases (Logout, api base oauth, CredentialsAuth, etc) is really makes a difference.

Example

next-auth/src/client/index.js

Lines 230 to 255 in 8115a7c

	// Redirect to sign in page if no valid provider specified
	if (!provider || !providers[provider]) {
	// If Provider not recognized, redirect to sign in page
	window.location = `${baseUrl}/signin?callbackUrl=${encodeURIComponent(callbackUrl)}`
	} else {
	const signInUrl = (providers[provider].type === 'credentials')
	? `${baseUrl}/callback/${provider}`
	: `${baseUrl}/signin/${provider}`
	// If is any other provider type, POST to provider URL with CSRF Token,
	// callback URL and any other parameters supplied.
	const fetchOptions = {
	method: 'post',
	headers: {
	'Content-Type': 'application/x-www-form-urlencoded'
	},
	body: _encodedForm({
	...args,
	csrfToken: await getCsrfToken(),
	callbackUrl: callbackUrl,
	json: true
	})
	}
	const res = await fetch(signInUrl, fetchOptions)
	const data = await res.json()
	window.location = data.url ? data.url : callbackUrl
	}

Cons (full redirects)

• Doesn't allow animated page transitions
• Is a lot slower
• Feels clunky
• Everything needs to be refetched when the auth state changes
• Is inconsistent with the tab share logic (see localstorage messaging)

Pros (full redirects)

• new state
• new env
• easier to get right

Proposal

The login flow could be much more fluent, if we switch or allow the usage of next client page transitions using next.router.push() and next.router.replace(), because we don't need to reinitialise the entire app.

Whats needs to be done to make next client transitions work

• Make next-auth context reactive (for all CRUD Actions)
• Differentiate between internal, external and api redirects
• Move responsibility of redirects to the client
• Release major version (this will be a breaking change)

What are you trying to do

Improve the login flow.

Can I help

If the next-auth team would be interested in such a change I could work on this topic.

Feedback

Documentation refers to searching through online documentation, code comments and issue history. The example project refers to next-auth-example.

• Found the documentation helpful
• Found documentation but was incomplete
• Could not find relevant documentation
• Found the example project helpful
• Did not find the example project helpful

[iaincollins]

Thanks for raising this and describing it in detail.

Essentially "easier to get right" is the main reason for this - it reduces the amount of problems people run into and the amount of requests for help using it that get raised.

A secondary reason is keeping the methods decoupled from Next.js to try to avoid being impacted by breaking changes in Next.js and to be framework agnostic, even to React; with longer term goals of being suitable as a solution for Nuxt.js and other frameworks (currently there are some dependencies request/response middleware in a few places, but those are easily refactorable).

The signIn and signOut client methods are the only methods that use window.location in this way (IIRC).

As noted, it's less of an issue with signIn as with OAuth or Email, the browser window needs to redirect to handle OAuth in any case so typically it's not something users perceive. It has the biggest impact on user experience in the Credentials Provider, where it is inadvertantly harder to handle different responses because of this - IIRC there is a ticket open about that already.

It would be nice to improve the behaviour on signOut but it's not been a priority - currently there are a lot of other things people want to see first, ahead of optimisations for either of these functions (it's not ideal behaviour, but in many cases it's not noticeable).

I do agree that these methods should not forcibly redirect in this way, with no way to prevent that. The intention is to add the option to not perform a redirect from these methods - e.g. by passing callbackUrl: false, redirect: false or some other option; though it could equally also be a function like next.router.push().

[giraffesyo]

Really great write up on the reasoning behind this, and it's interesting that you're considering expanding to other frameworks.

I do agree that these methods should not forcibly redirect in this way, with no way to prevent that. The intention is to add the option to not perform a redirect from these methods - e.g. by passing callbackUrl: false, redirect: false or some other option; though it could equally also be a function like next.router.push().

I think this would be a really great solution. In my current use case I'm only using the email authentication and I don't really need to redirect anyone, just displaying a little alert saying the email was sent would be sufficient, and make everything look way cleaner.

[ThewBear]

This could fix #532 #603

When login adds a hash to the url then hitting Signout button isn't refreshing the screen. It is logging out but a user can't tell. Is there any workaround to remove the hash being added by providers like Google to the browser url after callback?

[stale]

Hi there! It looks like this issue hasn't had any activity for a while. It will be closed if no further activity occurs. If you think your issue is still relevant, feel free to comment on it to keep it open. (Read more at #912) Thanks!

[balazsorban44]

This has been fixed by adding a redirect: false option to signIn and signOut.

https://next-auth.js.org/getting-started/client#using-the-redirect-false-option

https://next-auth.js.org/getting-started/client#using-the-redirect-false-option-1