🔥 Fire Burns The Ignorant - Featuring Arch - Day 2 Log

Abhay RajAbhay Raj
4 min read

I was kind of regretting switching from Ubuntu to Arch. ALSA (Advanced Linux Sound Architecture) is the main culprit. Falling head over heels for Arch’s slick terminal might’ve been a bit impulsive.

ALSA (Advanced Linux Sound Architecture) really burned my time. Every time I connect my headphones, Arch doesn’t care — I have to open alsamixer manually to adjust audio.

I even installed PipeWire to auto-detect earphones and switch audio output, but it didn’t work as expected. After about an hour of searching and trying, I gave up and decided to properly read about ALSA.

With great power comes great responsibility. Arch gives us deep control over our OS, but I guess I’m not responsible enough (yet) to wield that power in a civilized way.

I guess it’s time to read all my fundamental rights, fundamental duties and amendments that I can make from Arch wiki.

Btw I was joking. I am not regretting anything, I am actually enjoying the learning curve.

But before moving ahead with today’s blog, let’s discuss the solution of the problem statement I gave you yesterday.

import Post from './Post'
import NewPost from './NewPost'
import classes from './PostList.module.css'
import {useState} from 'react'
import Modal from './Modal'

export default function PostList({isPosting, onStopPosting}){
  const [enterBody, setEnterBody] = useState('');
  const [enterName, setEnterName] = useState('');

  function enterBodyHandler(){
    setEnterBody(event.target.value);
  }

  function enterNameHandler(){
    setEnterName(event.target.value)
  }

  return(
    <>
      {isPosting ?   
      <Modal onClose={onStopPosting}>
       <NewPost onChangeBodyHandler={enterBodyHandler} onChangeNameHandler={enterNameHandler}/>
      </Modal> : null 
      }

      <ul className={classes.posts}>
        <Post author={enterName} body={enterBody}/>
        <Post author="Manuel" body="Check out the full course!" />
      </ul>
    </>
  )
}

Your task was to figure out whether the function enterBodyHandler() and function enterNameHandler() will work correctly or throw error?

You might have come up with the logic that it will throw an error because event is not passed as parameter in the enterBodyHandler() and enterNameHandler(). And that is what I thought initially. But when I ran the functions without event being passed to the functions, it worked properly. NO ERRORS.

Browser behaviour peed over my smarty pants 🤢

In older browsers, or in non-strict mode, the event object is available as a global variable (window.event). So even if you don’t pass event as a parameter, event.target.value might still work.

However, React uses strict mode in development — and does not rely on or expose global event. So the fact that this worked might indicate:

  • You’re not running React in strict mode.

Your browser environment temporarily supported window.event.

If it does not, your code would fail with a ReferenceError: event is not defined error.

💡
It is a best practice to always pass the event object as a parameter to your handler, because React does not rely on the global event object.

So, always declare event as a parameter in your event handlers.

function enterBodyHandler(event) {
  setEnterBody(event.target.value);
}

function enterNameHandler(event) {
  setEnterName(event.target.value);
}

Talking about my progress

I have revised fifty percent of React so far. The course by Maximilan Schwarzmüller is quite good. I would have tagged him here but he is not on Hashnode. Poor guy!!

I feel the pace with which I am moving ahead with the course work is a bit slow. These days I am trying to shift to a more Keyboard focused workflow and saying no to he mouse pad. All this hardwork for getting blazingly fast with all my workflows. Neovim + Arch are devouring my time - But that’s how it goes. right??

If you’ve have stayed with me for this long, then I feel you’re interested to read more. God damn it!! I have to keep using these fingers quite for some time to squirt the hell out of your nerdy brains.

Do you guys know why do we use useEffect to fetch data, but call fetch() directly in event handlers?

When fetching the data you want to trigger the API calls only at certain times like after the component mounts or when certain dependencies change, not on every render.

If you use data fetch in a unconventional way as given below

import { useState } from 'react';

function MyComponent() {
  const [data, setData] = useState(null);

  if (!data) {
    fetch('https://api.example.com/data')
      .then(response => response.json())
      .then(json => setData(json))
      .catch(error => console.error(error));
  }

  return <div>{data ? data.message : 'Loading...'}</div>;
}

This might lead to an infinite loop of fetches and renders as React component can re-render many times due to state changes, props updates, or other filthy reasons.

By putting the data fetch inside useEffect you ensure the side effects like data fetch should run-typically only when the component first mounts, or when certain dependencies change.

import { useState, useEffect } from 'react';

function MyComponent() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch('https://api.example.com/data')
      .then((response) => response.json())
      .then((json) => setData(json))
      .catch((error) => console.error(error));
  }, []);

  return <div>{data ? data.message : 'Loading...'}</div>;
}

Save yourself from unwanted infinite loops and mental breakdowns.

If you made it this far, I hope I become as nerdy as you and keep pushing out good quality and quantity of technical content.

This is enough for your brain today.

Abhay Raj, signing out
📅 June 2, 2025

1
Subscribe to my newsletter

Read articles from Abhay Raj directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Abhay Raj
Abhay Raj

Hey, I'm Abhay Raj. I started my journey as a software developer at Infosys in 2021. After spending around two years there, I took a detour into marketing and copywriting. After some time, I realized that my analytical mind thrives more on solving complex, real-world problems than crafting emotional narratives. So, I jumped back into tech — and haven't looked back since. Beyond coding, I love traveling, working out, trying out adventure activities, and connecting with new people. I believe there's more to life than just writing code — and that's why I now work independently as a solo software developer.