DEV Community: nayem

this kept breaking my code, so i learned binding

nayem — Thu, 05 Nov 2026 05:35:10 +0000

Early in my first React job, I built a class component with a button. Click the button, the counter goes up. Very simple, maybe 20 lines. I clicked it and got TypeError: Cannot read properties of undefined. I stared at that error for a solid 40 minutes before the senior dev on my team walked over, typed .bind(this) in the constructor, and walked away like a surgeon closing an incision. I had no idea why it worked. I just shipped it and moved on.

For about two years after that, I treated binding like a superstition. See a class method, bind it, ask questions never. (It worked every time, which is the most dangerous kind of not understanding.) Anyways, this post is the explanation I wish someone had given me back then, plus the arrow-function-era update.

The one rule about `this`

this is decided by how a function is called, not where it is written. Read that again, because it is the whole post. When you write user.greet(), JavaScript sees the dot at the call site and sets this to user. When you write const f = user.greet; f(), there is no dot at the call site, so this is undefined (in strict mode, which is every module you will write in 2026). Detaching a method from its object strips its this off. That is it. That is the bug, every time.

the-trap.js

const user = {
  name: 'Nayem',
  greet() {
    return 'Hi, I am ' + this.name
  },
}

console.log(user.greet()) // "Hi, I am Nayem". The dot does the work.

const greetAlone = user.greet
console.log(greetAlone()) // TypeError. No dot, no this.

Live: the same function, two call styles
Try it live on nayemalam.com.

Try it. Same function, same object. One button calls it with the dot, one calls it without. The error message is the one that used to ruin my afternoon.

Where `this` bites you in real code

It is almost never the object-literal case that gets you. It is the callback case, where the function gets detached from its object silently, three files away from where the bug shows up:

Event handlers.onClick={this.handleClick} hands React the function without the object. React calls it later, dotless.
Timers.setTimeout(user.save, 1000) does the same thing, just with a delay, so the stack trace arrives when you have already forgotten what you wrote.
Array methods.items.map(this.renderItem) passes the method along and this never makes the trip.

Notice the pattern. You never wrote a bad function. You wrote a good function and then handed it to someone else, and the handoff dropped the this. (Like lending a friend your car without the keys. The car is fine.)

`bind`, `call`, `apply` (the old school fixes)

bind returns a new function with this locked in. call and apply run the function immediately with the this you hand them (apply takes an array of arguments, call takes them one by one). The full reference lives on MDN, but here is the 30-second version:

bind-call-apply.js

const user = {
  name: 'Nayem',
  greet(greeting) {
    return greeting + ', I am ' + this.name
  },
}

// bind: lock this in, call the result whenever
const bound = user.greet.bind(user)
bound('Hello') // "Hello, I am Nayem"

// call: run it once, right now, with this set
user.greet.call({ name: 'Alex' }, 'Hey') // "Hey, I am Alex"

// apply: same as call, but arguments arrive as an array
user.greet.apply({ name: 'Alex' }, ['Yo']) // "Yo, I am Alex"

Why arrow functions made most of `this` go away

Arrow functions have no this of their own. They borrow it from where they are written, permanently. So onClick={() => this.handleClick()} keeps the dot at the call site, and this survives. Same with setTimeout(() => user.save(), 1000). This is why the whole binding problem quietly faded when everyone moved to function components and hooks: we just stopped writing the code that triggers it.

One gotcha survives, though. Arrow functions make bad object methods, because their this comes from the surrounding scope, not the object:

arrow-method-trap.js

const counter = {
  count: 0,
  // arrow function: this is the module scope, not counter
  tick: () => {
    this.count++ // TypeError. Surprise.
  },
  // regular method: the dot does the work, as usual
  tickFixed() {
    this.count++
  },
}

The rule of thumb I actually use: arrow functions for callbacks, regular methods for objects. Each one puts this where you expect it.

The React version of this story

This is where my 40-minute stare-down happened. Class components need every handler bound, because onClick={this.handleClick} is exactly the detaching-a-method case from above. The classic fix is one line in the constructor:

class-component-bind.jsx

class Counter extends React.Component {
  constructor(props) {
    super(props)
    this.state = { count: 0 }
    // the line that haunted me for two years
    this.handleClick = this.handleClick.bind(this)
  }

  handleClick() {
    this.setState({ count: this.state.count + 1 })
  }

  render() {
    return (
      <button onClick={this.handleClick}>
        Clicked {this.state.count} times
      </button>
    )
  }
}

The shorter modern version is an arrow function as a class property, which keeps this as the component automatically because arrow functions borrow it from where they were written:

class-property-arrow.jsx

class Counter extends React.Component {
  state = { count: 0 }

  // arrow function, so this is the component. No bind needed.
  handleClick = () => {
    this.setState({ count: this.state.count + 1 })
  }

  render() {
    return (
      <button onClick={this.handleClick}>
        Clicked {this.state.count} times
      </button>
    )
  }
}

So, what have I learnt?

Look at the call, not the definition. If there is a dot before the function name when it runs, this is the thing before the dot. If not, this is gone.
A method passed as a callback arrives with its this stripped off. That handoff is where almost every one of these bugs lives.
bind locks this in for later, call and apply run once with the this you give them, and arrow functions borrow this from where they were written.
I cargo-culted .bind(this) in constructors for two years without knowing what it did, and the code worked the whole time. Understanding it did not make my code better. It just means I can read old class components without that lowkey dread, which, honestly, is the entire payoff.

Originally posted on nayemalam.com/blog.

easily understand flexbox

nayem — Thu, 05 Nov 2026 05:30:41 +0000

For the first three years I wrote CSS, flexbox and I had an arrangement. I would type display: flex, then guess at justify-content and align-items until the boxes landed somewhere reasonable. It worked about 70 percent of the time. The other 30 percent I sat in devtools toggling properties like a slot machine, hoping for three boxes in a row. (You know the feeling. Everyone knows the feeling.)

Turns out the whole thing is two axes and a handful of properties. This is the post I wish existed back then, with pictures, because flexbox is one of those things that clicks visually or not at all.

The only mental model you need

flexbox lays things out along two axes: the main axis and the cross axis. Every property you are about to learn answers one of two questions. Where do things go along the main axis? Where do they go along the cross axis? That is genuinely all of it.

The `display` switch

One line turns any container into a flex container, and its children line up in a row, left to right:

flex-basics.css

.container {
  display: flex;
}

That is the on switch. Everything below only works once this line exists, which is worth saying because I once spent twenty minutes wondering why justify-content was doing nothing. It was doing nothing because I forgot the switch.

`flex-direction` flips the axes

By default the main axis runs left to right (row). Set flex-direction to column and the main axis runs top to bottom instead. The axes flip, which means justify-content and align-items swap jobs. Forgetting this is why centering "randomly breaks" when you switch a layout from row to column.

flex-direction.css

.container {
  display: flex;
  flex-direction: column; /* main axis is now vertical */
}

`justify-content` runs the main axis

This is the one everyone mixes up, so here are all six values doing the same job on the same three boxes:

In practice you will use three of these for 95 percent of layouts: flex-start, center, and space-between. Learn those cold, look up the rest when you need them.

`align-items` runs the cross axis

Same idea, other direction. The default is stretch, which is why your boxes fill the container height and you never questioned it:

The centering trick, finally explained

The most googled CSS snippet of all time, and now you can read it instead of copying it:

center.css

.center {
  display: flex;
  justify-content: center; /* center along the main axis */
  align-items: center;     /* center along the cross axis */
}

Center on one axis, center on the other. Done. No absolute positioning, no transform hacks, no margin auto prayer.

`gap` killed the margin hacks

Remember putting margin-right on every child except the last one? gap does it properly, with even spacing that does not collapse or double up:

gap.css

.container {
  display: flex;
  gap: 12px; /* space between children, nothing else */
}

Try it live

Same three boxes. Flip the direction, move them along each axis, watch what changes. This is faster than reading my explanation a second time:

Live: flexbox playground
Try it live on nayemalam.com.

So, what have I learnt?

flexbox is two axes. Name the axis before you reach for a property and half the confusion disappears.
justify-content is the main axis, align-items is the cross axis. Mixing those two up was 90 percent of my problem.
flex-direction: column flips the axes, which is why centering breaks when you change direction.
Centering is two lines and now I know which two and why.
gap over margins, every single time.

Originally posted on nayemalam.com/blog.

DEV Community: nayem

this kept breaking my code, so i learned binding

The one rule about this

Where this bites you in real code

bind, call, apply (the old school fixes)

Why arrow functions made most of this go away

The React version of this story

So, what have I learnt?

easily understand flexbox

The only mental model you need

The display switch

flex-direction flips the axes

justify-content runs the main axis

align-items runs the cross axis

The centering trick, finally explained

gap killed the margin hacks

Try it live

So, what have I learnt?

The one rule about `this`

Where `this` bites you in real code

`bind`, `call`, `apply` (the old school fixes)

Why arrow functions made most of `this` go away

The `display` switch

`flex-direction` flips the axes

`justify-content` runs the main axis

`align-items` runs the cross axis

`gap` killed the margin hacks