Rethink v4 client > react renaming

[Izhaki]

I know that the ship has set sail on this, but maybe we want to reconsider the renaming of next-auth/client to next-auth/react.

First, I have worked on a few libraries that have React components and server/client element to them. I've ended up using these groups:

• client - frontend specific code.
• server - backend specific code.
• react - react components that are shared between the server and client.

At the moment, the library has react components (eg, email form) in places like src/core/pages/signin.tsx. These components are "iron-clad" to that page and anyone wanting a custom UI (say only for the email form) will need to create a custom pages/auth/signin.tsx page. If you want to render other providers, you'll have to copy the code from src/core/pages/signin.tsx.

There is an alternative, more compositional approach to this, which is to provide the form with the provider. So, for instance, the EmailProvider will have a configuration options called getSignInFrom.

We could extract the forms in src/core/pages/signin.tsx into their own scripts and export them, the question is where do these go? Currently they will only be needed in the server to config the built-in forms.

But, for use cases such as no-redirects, where these forms will live in the front-end (eg, on a dialog) users may wish to import them from the library. And then the question is: Where from?

So the client/server/react classification above does have sense.

I know that with the current state of things this will be a painful U-turn. But I do have to mention it.

[balazsorban44]

The name change is necessary because we plan to move to other frameworks/libraries like Vue and Svelte. client would have been a confusing name to keep around for React only.

If you need a custom page, you can create one just like any other page. The built-in pages are server-side rendered and not really meant to be customized other than applying changes through the theme option.