Also this type Readonly<{ params: { locale: Locale } }>) wouldn't work in next 15.

wdym

i am using nextjs15 and it didn't say anything to me

No error on build?

nope

You are having an antipattern there because pages shouldn't be client components to begin with.

And as the initial error suggests the params are a promise that you need to handle accordingly.

useParams works btw, thx

i tried to use React.use and it didn't work, i didn't see there was useParams

Using useParams is a bandaid though and not necessarily the correct solution to begin with. You should eventually evaluate to fix your page to make it a server component as intended.

Keep that in mind for the future.

i prefer to keep the auth pages client only

the other ones will be server

i don't want to send sensitive info as plaintext

I don't understand why that would happen to begin with.

Also keep in mind that a page that is a server component can have client components as children if you truly need it for something.

if it is authenticated, the sensitive data won't be generated without the auth anyway

it is the register and login page

If you host using https which you should there is nothing to worry about when submitting a form.

And this is completely unrelated to whether or not a page is a client or server component.

There seems to be a misconception that is happen to have picked up somewhere.

you do have to worry even with https

i tought server forms sends data to the server and then process it

Regardless of your form setup you'd be sending credentials to a server to auth the user.

Even with a "client side form" you'd be sending the input to the server.

i do encrypt it first tho

with a public key

Why would you? https is already doing exactly this.

well, not completely, if you are using services like Cloudflare, they can see the request data

And think of it that way: if you encrypt form data locally before submitting it an attacker can easily hook into your local encryption function and do whatever they want.

wdym, like send malicius DB queries?

In this case it won't matter too much if an attacker can alter your encryption function. It's just unnecessary in the first place since it secures you from man in the middle attacks. Just because Cloudflare could eventually access the submitted data doesn't mean you have to fully encrypt it. After all it will eventually relay the data to your own server using https again. So in this case you're advocating for encryption in the case that Cloudflare itself gets attacked? Assuming they have no safety measures in place.

i just prefer to be safe

Introducing custom measures offers just minimal advantages, if any, and often makes you vulnerable to more issues without you realizing. It's an industry standard to rely on the security of https rather than manually coming up with sophisticated solutions.