Today I learned 👇
redirect() runs on the server
It stops rendering the current page
Sends a redirect (3xx) to the browser
Browser requests the new URL
Current component is never rendered → React unmounts it
⚠️ When used in a Server Action:
await expects a normal response
redirect() interrupts it
Promise is treated as rejected
catch runs even if server succeeded
Lesson:
❌ Don’t use redirect() in Server Actions awaited by Client Components
✅ Let the client handle navigation
redirect() runs on the server
It stops rendering the current page
Sends a redirect (3xx) to the browser
Browser requests the new URL
Current component is never rendered → React unmounts it
⚠️ When used in a Server Action:
await expects a normal response
redirect() interrupts it
Promise is treated as rejected
catch runs even if server succeeded
Lesson:
❌ Don’t use redirect() in Server Actions awaited by Client Components
✅ Let the client handle navigation
💡 Difference between .then() and async/await
1️⃣ .then() style (Promise chaining)
2️⃣ async/await style (looks synchronous)
1️⃣ .then() style (Promise chaining)
something()
.then(result => {
return otherThing(result);
})
.then(final => {
console.log(final);
})
.catch(err => {
console.error(err);
});
2️⃣ async/await style (looks synchronous)
try {
const result = await something();
const final = await otherThing(result);
console.log(final);
} catch (err) {
console.error(err);
}💡 Async functions and Promises in JS
Any function declared with async automatically returns a Promise, even if you don’t return one explicitly.
Example:
✅ Conceptually, this is like the engine doing:
return value → becomes resolve(value)
Throwing an error → becomes reject(error)
So async = syntactic sugar over Promises.
await just pauses execution until that Promise settles.
Any function declared with async automatically returns a Promise, even if you don’t return one explicitly.
Example:
async function foo() {
console.log(5);
return 42;
}
const res = foo();
console.log(res); // Promise { 42 }
✅ Conceptually, this is like the engine doing:
function foo() {
return new Promise((resolve, reject) => {
try {
console.log(5);
resolve(42); // your returned value
} catch (err) {
reject(err); // if function throws
}
});
}
return value → becomes resolve(value)
Throwing an error → becomes reject(error)
So async = syntactic sugar over Promises.
await just pauses execution until that Promise settles.
Original async/await code:
Equivalent manual promise wrapping of the async function body
✅ What this shows
Outer Promise → wraps the entire async function body (what async function automatically does)
Inner Promises → fetch() and response.json()
await → corresponds to .then() chaining internally
resolve() → happens when the function completes
reject() → propagates any errors
async function getData() {
const response = await fetch(); <==> fetch().then(...)
const data = await response.json(); <==> response.json().then(...)
console.log(data); <==> runs in the last then
}
async function getData() {
const response = await fetch("https://api.example.com");
const data = await response.json();
console.log(data);
console.log("After fetch inside async");
}
getData();Equivalent manual promise wrapping of the async function body
function getData() {
// Manually wrap the whole function body in a Promise
return new Promise((resolve, reject) => {
// Start fetch (already returns a Promise)
fetch("https://api.example.com")
.then(response => {
// Wait for response.json() (also returns a Promise)
return response.json();
})
.then(data => {
// This is everything after the await in the original async function
console.log(data);
console.log("After fetch inside async");
resolve(); // resolves the outer promise when the function finishes
})
.catch(err => {
reject(err); // reject the outer promise if any inner promise fails
});
});
}
// Calling it
getData().then(() => {
console.log("getData() finished");
});✅ What this shows
Outer Promise → wraps the entire async function body (what async function automatically does)
Inner Promises → fetch() and response.json()
await → corresponds to .then() chaining internally
resolve() → happens when the function completes
reject() → propagates any errors
async function getData() {
const response = await fetch(); <==> fetch().then(...)
const data = await response.json(); <==> response.json().then(...)
console.log(data); <==> runs in the last then
}
TypeScript protects you at compile time, but runtime data must be validated manually if you want to be safe
I was today years old when I realized VS Code is basically a browser
It’s a client that sends our code (what we type) to a Language Server using the Language Server Protocol (LSP)
like a mini internet inside my PC
The Language Server (e.g. TypeScript server) reads that code, analyzes it (types, errors, hints, autocomplete…),
and sends results back all locally, no internet involved
It’s literally a client-server architecture without network just process-to-process chat happening inside your machine
VS Code shows the squiggly lines, errors, and smart suggestions instantly
all thanks to that invisible “local server” running in the background
That’s what we mean by compile time in TypeScript this whole path is how your code gets checked before actually running.
TypeScript won’t even let it execute if there’s a type mismatch or syntax error,
because it’s constantly talking to the TypeScript server to validate everything in real time.
And imagine… this happens every time you press a key.
Every keystroke triggers this tiny local “client-server” check inside your machine 🤯
It’s a client that sends our code (what we type) to a Language Server using the Language Server Protocol (LSP)
like a mini internet inside my PC
The Language Server (e.g. TypeScript server) reads that code, analyzes it (types, errors, hints, autocomplete…),
and sends results back all locally, no internet involved
It’s literally a client-server architecture without network just process-to-process chat happening inside your machine
VS Code shows the squiggly lines, errors, and smart suggestions instantly
all thanks to that invisible “local server” running in the background
That’s what we mean by compile time in TypeScript this whole path is how your code gets checked before actually running.
TypeScript won’t even let it execute if there’s a type mismatch or syntax error,
because it’s constantly talking to the TypeScript server to validate everything in real time.
And imagine… this happens every time you press a key.
Every keystroke triggers this tiny local “client-server” check inside your machine 🤯
design thinking. by David kalle,
a friend of Steve jobs.
https://youtu.be/GYkb6vfKMI4?si=N5RFwbJGsWyq7r-Z
a friend of Steve jobs.
https://youtu.be/GYkb6vfKMI4?si=N5RFwbJGsWyq7r-Z
JavaScript Async Flow & Promises
JavaScript is single-threaded, meaning only one thing executes at a time on the call stack. When we call an async function like fetch(), the function itself runs briefly on the call stack, immediately returning a pending Promise, so the synchronous code continues without waiting. The actual async work (e.g., network request, timer) happens outside the JS thread in the browser or Node environment.
Once the async task completes, the engine marks the Promise as fulfilled or rejected. Any .then() or .catch() callbacks attached to the promise are pushed into the microtask queue, not executed immediately. The event loop continuously checks: when the call stack is empty, it drains the microtask queue, moving each callback back onto the call stack for execution.
In short, Promises + event loop + microtasks allow JS to handle async operations without blocking the main thread, ensuring smooth execution. Immediate promises like Promise.resolve(10) simulate this behavior instantly, while real-world async tasks like fetch() take time but follow the same flow.
JavaScript is single-threaded, meaning only one thing executes at a time on the call stack. When we call an async function like fetch(), the function itself runs briefly on the call stack, immediately returning a pending Promise, so the synchronous code continues without waiting. The actual async work (e.g., network request, timer) happens outside the JS thread in the browser or Node environment.
Once the async task completes, the engine marks the Promise as fulfilled or rejected. Any .then() or .catch() callbacks attached to the promise are pushed into the microtask queue, not executed immediately. The event loop continuously checks: when the call stack is empty, it drains the microtask queue, moving each callback back onto the call stack for execution.
In short, Promises + event loop + microtasks allow JS to handle async operations without blocking the main thread, ensuring smooth execution. Immediate promises like Promise.resolve(10) simulate this behavior instantly, while real-world async tasks like fetch() take time but follow the same flow.
❤3
I came across a post and its comments that really made me think.... [The post] and this tech nerd post too [the post] .......
For a long time, I’ve been hesitating to make this channel public.
But now I understand something simple:
"If you wait until you feel confident, you’ll never start anything."
Let’s grow together😊 . If u are senior kindly request to guide me and review my work through the progress too.
https://t.me/code4Lifee
For a long time, I’ve been hesitating to make this channel public.
But now I understand something simple:
"If you wait until you feel confident, you’ll never start anything."
Let’s grow together😊 . If u are senior kindly request to guide me and review my work through the progress too.
https://t.me/code4Lifee
Telegram
Learning Log
Documenting my learning journey.
A2SVian.
Sharing my Projects
A2SVian.
Sharing my Projects
Do you know this? 🦖
The dinosaur in the Chrome Dino, the little game that appears when you're offline, is meant to say That u are in the dinosaur era..... 😒
and now I'm in a situation with poor connection… so I'm playing it 😭
BTW, you can also play it even when you're online.
Just type this in your browser: chrome://dino. 😁
The dinosaur in the Chrome Dino, the little game that appears when you're offline, is meant to say That u are in the dinosaur era..... 😒
and now I'm in a situation with poor connection… so I'm playing it 😭
BTW, you can also play it even when you're online.
Just type this in your browser: chrome://dino. 😁
Forwarded from JavaScript
In CSS is DOOMed, Niels Leenheer shows off how he implemented a version of 1993's Doom using purely CSS rendering (with the game logic in JavaScript). Play it for yourself or check out the code.