👋 Welcome to Learning Log

This is my personal space to document and share my journey as a software developer and as a person growing in life, thought, and faith.

Here, I’ll share:

• Learning progress — currently focused on full-stack web development(typescript) and sometimes Flutter. After a year focused on DSA at A2SV, I’m now fully focused on learning and building real-world products.
• Projects & experiments — small builds, exercises, and hands-on explorations.
• Mistakes & lessons — from coding, learning, and life.
• EUREKA moments (aha moments) — insights that suddenly click while learning dev, life, and belief.
• Thoughts & questions — on software, belief, philosophy, science, and what truly matters.
• Ideas & discussions — exploring decisions, priorities, and how things really work.

If you’re reading this, welcome 😊

React Async Rendering – What Confused Me & What Finally Clicked

I was confused about why async/await works in normal JS, but fails in React client components.
At first it felt inconsistent… but here’s what finally made sense 👇
1️⃣ React client components render synchronouslyWhen React renders, it expects JSX immediately.If a component is async, it returns a Promise, not JSX — and React can’t handle that.
That’s why await directly inside a client component breaks things.
2️⃣ Then why does useEffect work?Because useEffect runs after the render.React renders the UI first, then async work happens later — no blocking.
3️⃣ Why async works in Server ComponentsServer components run on the server.They can await, and React sends HTML only after data is ready.
4️⃣ Where Suspense fits inReact does support async UI — but only when React controls it.Suspense pauses part of the UI, not the whole render.
Final understanding:
Async is not the problem Async during client render is. It’s only allowed when React manages it (Server Components or Suspense).

Reading data → Server Components
Writing data (mutations) → Server Actions
Complex client state → Client Components
Public APIs → API Routes (still valid)

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

💡 Difference between .then() and async/await

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:

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.