Don’t tell me you don’t know await is rogue too, jess christ.
Tell me what is going here.
CODE_BLOCK_0
Example by Thomas
Right there is a thenable, a big time Javascript interface implemented in .then callback chaining.
Or as MKRhere like to put it
“An object that exposes a then method is a Thenable”
Now let’s explore some more interesting things.
Let’s quickly reiterate on a fundamental definition.
A Thenable is simply an object with a INLINE_CODE_4 method. That’s it. No fancy constructors, no INLINE_CODE_5, no specific internal slots. Just a method named INLINE_CODE_6.
Think about it, the INLINE_CODE_7 specification itself relies heavily on the INLINE_CODE_8 method. It’s the core of how asynchronous operations are chained and resolved. And INLINE_CODE_9, bless its rogue little heart, just says, “Hey, if you’ve got a INLINE_CODE_10 method that behaves like a INLINE_CODE_11 method, I’m good. I’ll wait for whatever value you pass to that function.” that’s incredibly pragmatic in my opinion.
Now, if we internalize this, what else becomes possible? What if we don’t even need a INLINE_CODE_12 at all to INLINE_CODE_13 something? Thomas’s example with INLINE_CODE_14 is simple enough. But what if the “value” isn’t immediately available? What if it’s… delayed?
Imagine we’ve got a function that simulates fetching a user’s profile, but instead of returning a INLINE_CODE_15, it returns a plain object that just looks like a promise.
Scenario 1: The ‘Fake Promise’ that’s totally legit to await
CODE_BLOCK_1
Expected output:
Application starting. Fetching user 1… User 1 fetched! Awaited user 1: { id: 1, name: “User 1’s Profile”, status: “active” } Fetching user 102… User 102 fetched! Awaited user 2: { id: 2, name: “User 2’s Profile”, status: “active” } Application finished.
Surely that looks fantastic right?, lesser overhead than using new Promise();
Here’s a real life use-case in from Prisma docs.
If you have, probably written code that looks suspiciously like this:
CODE_BLOCK_2
Well mostly we will just run…
CODE_BLOCK_3
But in their implementation, It’s a form of lazy execution provided by implementing the thenable interface.
When NOT to go rogue
-
Tho powerful, custom thenables can be harder to debug if their INLINE_CODE_16 method is too complex or deviates from expected promise-like behavior. Native Promises often provide more consistent guarantees.
-
“The INLINE_CODE_17 Connection”: Explicitly showing how INLINE_CODE_18 works, as INLINE_CODE_19 uses a similar internal mechanism.
How new language features might standardize some of the patterns custom thenables can achieve, is something i’m i will be watching for.
If you have some interesting additions, let’s chat in the comments :)