When 'perfect' Code Fails

always nice to read about these things. i like the note on 'all tests were green'. it sounds like the test of this function only test for the good case right? it should also test a false case? or am i missing something here?

I think you're looking for `import 'server-only'` and not "use server";. Use server exposes functions as endpoints to the client. I.e. they are simply obfuscated api endpoints without boilerplate. Their main use is for mutations such as a form submission from the client.

Since pages are, by default, SSR, you don't need to have the server call out to itself to run an endpoint to check permissions. Instead, the server should just run the function.

I'm pretty sure Next does some behind the scenes black magic optimizations and doesn't actually make an API request over the wire, but it's still running through some layer of abstractions (causing it to be async) to run the function when instead it could simply be a synchronous function if implemented properly.

These abstractions make sense if you know how to use them properly, but I honestly blame Nextjs for the whole server action confusion. I remember when they first came out and seeing how almost every single question on /r/nextjs was about being confused about server actions. All these footguns and confusion to avoid some boilerplate... I'm not sure if they've improved it since, but I've moved to Svelte and haven't looked back.

> The snippet above was called as a server function. This is React's new way of calling server side code from the client side.

Tangential to the post, but mixing client-side and server-side code sounds like a recipe for disaster. There are already one too many services that perform authorization client-side, and I have a feeling making it harder to tell what runs where only makes the situation worse.

This is why you should:

- Write functional tests, not unit tests

- Not use compilers or other systems that do a lot of black magic (like changing the type signature of your functions (!))

> When we called the isOwner function, it returned a Promise even though our function signature did not specify it as an async function. Our synchronous-looking function was invisibly converted into an async function. This meant it no longer returned a boolean, it returned a Promise.

Oh God.

I don't know next.js, can someone explain how the client side can call a server function inside of an IF on the client side for security? It seems like there would be a trivial bypass of the security from the client side.

And still there are coders who prefer non-statically typed languages, tsk tsk...

IMO, the idea of trying to blur the line between client and server is a big mistake. I worked on WebSocket frameworks in the Node.js space so I was also tempted but I completely abandoned this approach years ago. Though with Node.js, I do often reuse utility functions between client and server, I reject any framework which tries to hide the separation. I demand to have complete understanding of where the code is executing and how. I need to know what is being executed, where and how.

I also avoid technologies where the code I write is different from the code being executed. This is why I've been avoiding TypeScript. It performs code transformations which obfuscate my understanding of the logic which will be executed. With TS, the code I write is not the code which gets executed. This is scary to me. My code gets compiled into some messy junk-looking code and then that messy junk gets executed in ways I don't fully comprehend.

Oh man! How did these guys even debug?

This does not conflict with Andrew Kelly's point! The software is not your js code!! Your js code is s tiny fraction of the software. The rest of it (including node) has serious design issues. JavaScript is an messy interpreted dynamically-typed language with a week type system that was designed for browser 30 years ago and even its creator discourages you from using it now.

My first thought was is JavaScript === case insensitive for string comps, because while I do use minimal JavaScript to enhance some web pages functionality it’s all basic vanilla JS.

But the answer is actually batshit crazy.

I suspected it would be some feature of this moronic joke of a language and it seems I was right.

This reminds me of functions that rely on properties, but the properties could, themselves, be functions (in Swift, we call them "computed properties," and they are indistinguishable, on the outside, from stored properties).

C++ can also have a lot of tripwires, from overloaded operators (same with Swift, but people don't overload operators very often, in Swift. They compute properties, all the time, though).

It seems like the root cause was implicit conversion to boolean type. Stricter programming languages don't allow this. And even in statically-typed languages allowing this (C++) it's possible to disable such behavior via a compiler warning option.

> It is written as if this only applies to functions you mark with use server and not the whole file.

The demonstration code illustrating the problem uses a file-level "use server" directive (and doesn't have other functions in the same file with the problem isOwner function); if they were using function level "use server" directives and it impacted a different function in the same file, I would say this is clearly surprising and unexpected (and even buggy) behavior, but this seems to be using a clearly documented feature and getting exactly what is advertised.

> Let's look at the following Javascript snippet:

Title checks out, say no more.

> The snippet above was called as a _server_ function.

A semantic shift in what a function is.. lovely. Is this Javascript or Python?

"The Power of 10 Rules" (2006, Gerard J. Holzmann)

https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...

Generally wise advice. =3