DEV Community: Sid

So you want to start a blog

Sid — Fri, 24 May 2019 05:50:50 +0000

I wrote this post for my newsletter, sign up here to get emails like these every week.

Before I started my blog/newsletter ~ 11 months ago, I had a lot of reasons not to. Most of these are insecurities disguised as excuses.

Let's pick them apart one by one.

I don't have anything interesting to say

Let me be the first one to tell you - Your point of view is unique and I would love to hear it.

All of us work on similar things and engage with the same technologies, but all of us have a different way of looking at the world.

When you write a blog post, you are sharing your point of view. Folks who share your world view will find it relatable, that's great. They might not have the same point of view and get a chance to see the same thing from a different perspective, that's also really valuable.

Think about what you have learned or done in the last 6 months that was new for you - make a small list of potential blog posts titles.

I'm not experienced enough to write an article

If you are learning something new and don't feel like an expert, here's a secret: Nobody feels like an expert.

In the javascript space, there's so much to learn and it changes so fast.

Small detour into what Eric Elliot wrote about javascript fatigue because I think it's a great perspective:

Learning JS can be overwhelming. I know it can feel like there is an ocean of stuff you don’t know. Trying to soak it all up is like trying to soak up the real ocean with a beach towel.

It’s never going to happen. I can’t keep up. Dan Abramov isn’t keeping up. Brendan Eich isn’t keeping up. Don’t stress out because you can’t, either. We’re all on the same bullet train here, and no matter what seat you’re sitting in, the world outside the windows is all a blur.

We “experts” know a lot about our little corners of the web platform, but we don’t know every little thing about every little thing. If you’ve been at it more than a year or two, chances are very good that you know a lot of stuff I don’t know about web development. I’m cool with that.

All that to say, waiting till you "become an expert" is a waste of time. We can all contribute with what we know today. With anything that you learned this year, there are hundreds around you that want to learn that.

There's this quote I really like: "Document, not create".

We're not inventing new things here. At best, we're discovering patterns. Share as you learn. I wrote an entire series about writing Good Components, I didn't invent any of those patterns. I learned them from others and presented them from my perspective and examples.

I just started learning, I'll share more when I have more knowledge

If you just learned something, you have a perspective that is more useful than someone who is doing this for a while.

After working with React (and javascript) for a while now, there are a lot of weird quirks that I take for granted. I have to constantly remind myself not to use technical jargon that would alienate someone new.

I have stopped conducting beginner workshops for React because I'm simply not a good teacher for that anymore. If you are in the learning new things stage, your fresh perspective will help others in the same stage.

What If I make mistakes?

This one is the hardest for me. What if I say something that I believe to be true, but it turns out wrong. Or worse, what if I share an opinion that's works for me but harmful for others.

I try not to be wrong. I do my research before putting something in an article, I'll run all the code that I show as examples.

That fear is sometimes a feature not a bug - it helps you to put in the work and reach a layer of understanding that is deeper than you had before. It helps me choose my words wisely and become better at communicating.

But most of the times, the fear is just a bug - it's my imposter syndrome talking. It's easier to keep my thoughts to myself and never find out if I'm wrong.

Here's the thing, it's okay to be wrong. The folks who read your article won't hold it against you as a person. You might get a mean comment on rare occasions, but trust me, you get over that after a few times because the folks who you're able to help would be way higher.

I have a topic in mind, but will anyone find it interesting?

This happens to me almost every week. I have a post in mind but I'm not sure if it's interesting to others.

It's impossible to write for the masses, you can't please everyone. It helps to keep a specific person in mind when you're writing - you're only trying to help one person. Chances are there are plenty others that will benefit from the same article.

Bonus: This style of writing feels personal to the reader which makes it more enjoyable.

When it's your own blog, you get to do whatever you want. You are writing for yourself (and for that one person). If you feel like writing about a topic, go for it!

Even if I write it, nobody will read it

If you're just starting out, I hear you. If you don't have folks that you can send your article to, it's hard to find the motivation. I've been there.

Fortunately for us, we are part of a very welcoming community.

You can post your article on community sites like dev.to, hashnode and spectrum or submit to medium publications like freeCodeCamp and hackernoon.

All of the above are way more fun than reddit/hackernews. dev.to is my favorite right.

I just need to rebuild my blog before I start writing

The best designed blog wouldn't be helpful if there are no posts on it. This is usually a way to procrastinate.

Clone a starter kit and start writing. Hell, you can even write your posts in a public GitHub repository and share them.

When you have some posts rolling and some folks reading them, it will be more fun to over-engineer your blog.

Hope that was useful and gives you a tiny nudge to start

Sid

Why do we keep talking about CSS-in-JS?

Sid — Tue, 07 May 2019 04:03:23 +0000

Remember the first time you wrote some html/css? It was amazing, right?

<div style="color: blue">Hello world</div>

So simple, so pure.

Then, of course, the senior developer™ told you not to write your css like this and put it a separate file.

<div class="blue-text">Hello world</div>

/* style.css */
.blue-text {
  color: blue;
}

As you build more elements and pages, your style.css starts getting long, so you split it into multiple files.

/* landing-page.css */
.heading {
  font-size: 64px;
}
button {
  background: orange;
}

/* forms.css */
button {
  background: blue;
}

Soon, you realise that styles intended for one element start clashing and overwriting others. You adopt some form of name-spacing to create a scope for these styles.

Maybe something as simple as this:

<form>
  <input placeholder="email" />
  <button>Submit<button>
</form>

/* form.css */
form button {
  background: blue;
}

Or something more advanced like BEM:

<form class="form">
  <input class="form__input" placeholder="email" />
  <button class="form__button">Submit<button>
</form>

/* form.css */
.form__button {
  background: blue;
}

I really liked BEM (and other convention based methods like OOCSS, ITCSS, etc.). You can solve a hairy problem by merely adopting a common convention in your team.

Either way, the problem you are solving here is of scoping styles to a specific context.

The same problems and solutions are carried into React land as well. Take this LoginForm for example:

function LoginForm() {
  return (
    <form className="form">
      <input placeholder="username" type="text " />
      <input placeholder="password" type="password" />
      <button className="button">Submit</button>
    </form>
  )
}

We have no idea if that button is going to clash with another button in the application somewhere else. We should use some sort of scope here. You can still use namespacing like BEM here with React.

<button className="form__button">Submit</button>

This is where the story get's interesting. In a React component, we aren't writing plain HTML anymore, we are writing JSX.

The above line of JSX is converted to this block of javascript at build time:

React.createElement(
  'button',
  { className: 'form__button' },
  'Submit'
)

You have the full power of a programming language (javascript) at your disposal now. You can do things which wouldn't be possible with pure CSS.

The promise of CSS-in-JS

You can defer the job of creating a scope or name-spacing to the language instead of doing it manually.

CSS Modules is the gateway drug the of css-in-js ecosystem.

This is what you write:

/* form.css */

button {
  /* look ma, no name spacing */
  background: blue;
}

import styles from './form.css'

function LoginForm() {
  return (
    <form>
      <button className={styles.button}>Submit</button>
    </form>
  )
}

And this is what styles.button get's compiled to:

function LoginForm() {
  return (
    <form>
      <button className="form__button__abc1">Submit</button>
    </form>
  )
}

This is very similar to what you would write by hand, but it frees you up from the responsibility of avoiding conflicts. I find it incredibly liberating to be able to write my styles as if they were locally scoped.

The next wave of CSS-in-JS libraries

We were able to leverage the power of the language in the tooling/automation bit, can we also bring it to writing styles?

This is where it becomes controversial. Each CSS-in-JS takes a slightly different approach to enable a certain new feature by making a tradeoff.

For example: jsxstyle lets you write styles that look like classic inline styles on the element but extracts them out into a file through a webpack plugin.

<Block component="button" backgroundColor="blue" />

On the other hand, styled-components lets you mix runtime logic inside css. This means you can start using it without touching your config but you can't extract the styles out.

const Button = styled.button`
  background: ${getBackground};
`

function getBackground(props) {
  if (props.appearance === 'primary') return 'blue'
  else if (props.appearance === 'disabled') return 'grey'
  else return 'white'
}

linaria takes an interesting middle route with its css tag, you can create classes right next to the component and these extract them out during build using a babel plugin. This means you can still use javascript but it can't depend on runtime logic like the previous example.

const button = css`
  background: ${colors.blue};
`

function MyComponent() {
  return <button className={button}>Click me</button>
}

As you can see, all of these libraries bring something to the table in exchange of a something else. This is why it's so controversial, you can take any library and find flaws in it.

css-modules automates the work of namespacing styles but requires some setup which can be looked as over-engineering (we already have manual BEM that works without any setup)

styled-components on the other hand does not require any babel/webpack setup but it requires the library to be present on runtime, increasing the size of your javascript bundle by a small amount.

You must choose the tradeoff that works for your project.

With the design system in Auth0, we chose styled-components because it helped us create flexible components based on a set of underlying tokens and design patterns.

Last week, I had to build a bunch of pages with some form logic in them and really enjoyed using css-modules because it helped me write both global and page specific styles without adopting a manual methodology like BEM.

You can use this comparison table that my friend Michele Bertoli created.

Hope that was helpful on your journey

Sid

React.lazy API in 60 seconds (Code-Splitting with Suspense)

Sid — Mon, 22 Apr 2019 05:52:52 +0000

Lessons learned from starting a small conference

Sid — Mon, 22 Apr 2019 05:38:52 +0000

I wrote this post for my newsletter, sign up here to get emails like these every week.

I'm prepping up for a big project right now. And it's definitely out of my area of expertise. My heart is excited but my brain tells me I have no business even attempting this. I'd like to tell you (and myself) a story the last time I thought I should "stay in my lane".

I went to a bunch of conferences last year and I had a great time in most of them. Conferences are great for getting inspired from the talks, meeting old friends and making some new ones.

But, here's the thing, I only watch half the talks. Sitting and listening to one talk after another gets boring real fast. You can always watch the rest of the talks later on youtube at 1.5x.

Instead, I like to spend time talking to people that I don't see very often.

I don't know why we look so sad, it was a happy conversation!

As an introvert, I find it really hard to just walk up to a stranger and introduce myself. But, when I give a talk, it's an invitation for others come talk to me after the talk about a topic I already like, which makes it so much easier 😇

Most conferences have a jam-packed schedule with short coffee breaks after every few talks. This forces you to pick - you can either have a long conversation with someone or cut that short and attend the next talk. I usually end up missing talks that I wanted to attend.

I realised I got the most value out of a conference by having deeper conversations about the topics I really care about and feeling inspired. This could be with a speaker after their talk or with fellow attendees.

This is my biased experience with conferences, I also know folks who like to attend all the talks, absorb everything like a sponge and synthesise them later. Whatever works for you!

I wanted to attend a conference that focused on the parts I like - longer meaningful conversations. An event other folks like me would enjoy.

Couldn't find any. From my experience with helping out with the first ReactFoo, I know organising a conference isn't a small task.

It takes sponsors and ticket sales and speakers and marketing and an auditorium and catering and audio visual setup and so much more. I didn't really think about it for a few months until I attended another conference.

Screw it, I'm gonna do it - Me

I always start all my projects with the website because it forces me to explain the idea clearly in a few words.

I knew the kind of conference I wanted to host.

This conference is designed to involve everyone in the discourse with short talks and plenty of time for discussions and follow-up conversations.

It's really difficult to create an involving 400 people. Small group, meaningful conversations seems more like the experience I'd enjoy.

I was really creating a conference for myself and hoping I can find a few other people who would enjoy the same experience.

Need speakers for a conference, right? Something that can serve as jumping off points for the conversations.

I wrote down "8 speakers, 25 attendees". Called it tinyconf.

You don't need an auditorium for 25 people, got in touch with my friends at Geeky Ants for their office venue, they have a meetup space which can fit everyone. (shoutout to Maheshwari for all the help!)

To create a space where you can have meaningful conversations, we removed Q&A after the talk. The Q&A are always too rushed to get a wholesome answer.

Instead we put a 30 minute break after every 2 talks (which were a crisp 20 mins) and an hour long lunch.

Talking of lunch, you don't need catering to feed a small of group, we just ordered lunch using one of the food delivery apps.

Next step, convince 8 people to come and give a talk.
If I'm creating the perfect conference experience, I'd love to have a diverse set of speakers. I got in touch with a few friends for help.

We didn't have international speakers* but we had a gender balanced lineup with a mix of first time speakers and experienced speakers.

*well, we kind of did. Pavithra was already in town from Australia.

I added speakers to the website and announced the conference on twitter a day before opening up sales to build up some hype. The next day, early bird tickets were sold out in 20 minutes! This was validation that there were others like me that really wanted a similar experience.

Because it was a really small event event, the tickets didn't have to priced high. We didn't even need to find sponsors! Hashnode offered to sponsor anyways and we were able to add some diversity tickets.

I was still feeling really under confident. This wasn't as fancy as the other conferences people are used to. They will be disappointed and call me out for scamming them! The format was too different, people will be bored between talks, etc.

But, It was too late to get cold feet now, people had already bought tickets!

I was surprised how well things turned out.

We had talks about State management, React Native, Animation, GraphQL and even a talk about stealing ideas from Vue.js 😋. There were plenty of things to talk about! The breaks didn't feel long at all, everyone was excited and nerding out over the details, it was great.

We did't have any conference swag, I brought a few stickers from my stickers side project and Nash (one of the speakers) brought t-shirts 🙌

The food was alright, we only had vegetarian because I forgot to ask for preferences in advance. 🤷

Overall, it felt like everyone had a good time.

I talked to a few folks for feedback and they weren't too sad. Twitter confirmed this feeling.

What's the lesson here?

In our heads, we sometimes create a picture that is so perfect that it seems unattainable. But if you push the fear aside for 5 minutes, you can break it down to see what are the parts that you really need and what parts exist to satisfy your fear.

I just came back from React Amsterdam which had over 1200 attendees! To throw an event that big and sell as many tickets, you do need international speakers and sponsors to fly them there and a really big venue. It's a great conference, but that's not the only way. There's plenty of room for tinyconfs as well.

In my case, I didn't need an auditorium or sponsors to host a good conference, I needed a date and a handful of excited people. Everything else is gravy. The hardest part is to start, after that, everything else falls into place.

Next time you feel you can't, watch this video.

Hope that was helpful on your journey

Sid

Week of April 02 - Top 3 React articles from around the web

Sid — Tue, 02 Apr 2019 14:32:33 +0000

1. How to Avoid the Boolean Trap When Designing React Components by Filip Danić

Using CSS conventions from Bootstrap for the API design of your React components can lead to bad decisions. Here's what you can learn from "The Clean Code" by Robert C. Martin in the context of React.

2. Building a Componentized and Reusable Scroll to Top Feature in React by Sarah Sweat

One of the main considerations in creating this component was that I needed it to be reusable on multiple pages of the site, so my goal was to create something that could be imported and utilized in other react components in order to add to a div which had content that would need to be scrolled through.

3. react-frontload (library) by Dave Williams

Load data asynchronously into your React components. Works on both client and server render.

Get emails like this in your inbox, every Tuesday . Short and sweet. No spam.

The best time to write tests

Sid — Tue, 02 Apr 2019 14:21:59 +0000

I wrote this post for my newsletter, sign up here to get emails like these every week.

Me, from the past:

"Writing tests for my code is pointless. I just tested my code, writing tests for them doesn't add any extra value.

And every time I change the code, I also have to change the tests because they become outdated."

It took me a while to realise that testing code isn't useless, my testing workflow was useless.

Maintaining a good test suite with respectable code coverage is hard. It always feels like more work and is the first thing that gets left out when you're short on time. If you want to keep a healthy test suite, should you write tests before you write the code or immediately after it?

Here's what I do: I don't write tests when I write a new feature. I write them just before I have to change it.

Let me explain,

For each desired change, make the change easy (warning: this may be hard), then make the easy change – Kent Beck

That's my favorite quote on maintaining code. I had to read that a few times before I understood what it meant -

When you write a block of code, you write it with the best understanding and the latest information you have at that time.

Months later, you have to extend this code to add support for another use case. You will have to fit this new logic on top of existing code. It works but isn't always the prettiest result. Your code becomes complex because it wasn't originally written with this new feature in mind. Next week, someone in your team will call this "legacy code".

If you had all this information from the start, you would have written the original code very differently. It would be able to accommodate this feature in a clean way. But, of course, we're not good at predicting the future.

Kent Beck suggests that instead of trying to force fit the new use case on top of the existing code, perform the change in 2 steps:

make the change easy (to perform)

First, refactor the exiting code to make it look like you knew this new feature was coming from the start.

then make the easy change

Next, add code to support the new use case. This part is fairly easy because your code is built for this change.

This approach really resonates with me. You're always refactoring code to keep it fresh.

And you don't have to ask for time or permission to pay tech debt because you're constantly reducing it while you add new features. The code never becomes "legacy".

On the surface, it might look like this will slow you down because you're doing more work. In my experience, it's almost always faster than making the hard change because you don't spend any time trying to understand complex code or fixing regression bugs.

As you can imagine, it would be incredibly handy to have tests in this scenario. But, do I already have them? Probably not.

Here's my workflow:

I start by writing tests for the existing block of code.
Then, I refactor it to make the new change easier to introduce. The tests help make these changes faster without breaking any existing features.
When that's done, I make the easy change of adding the new feature and tests to support it.

Make the change easy, then make the easy change.

When needed, I would create 2 different pull requests - one that introduces tests and shows that they still pass after refactoring and the second which adds the new feature.

Both of these pull requests breeze through the review process because the reviewer is looking at simplified code and has the confidence of tests. Can't the same about a pull request which tries to implement the hard change on top of existing logic.

Note: On a lazy day, I would often just shove the new feature without making an effort. And that's okay, you can't be on your best game everyday. This does, however, comes back to bite me either with long code reviews or bugs that slipped in or simply more refactoring the next time I need to touch this code.

There are 2 things I'd like you to point out in this workflow:

The best time to write tests for a feature is just before you change it.

If you are working on a codebase that does not have tests, you can start adding them whenever you have to make a change that looks difficult.

The part of your codebase which changes frequently is the one that will benefit the most from tests. Chasing code coverage for the sake of it will not improve your app.

2) Tests are not just for catching bugs.

With the above approach, tests can help you create a to-do list of use cases that can be checked one by one ✅

Once you know what logic needs to be written, the rest of the work is to simply type it.

This workflow helps me get the benefit of tests even when I'm not able to invest a lot of time up front.

I've learned the best methodology is the one that works for you and helps you write better applications.

Hope this was useful on your journey!

Sid

Pirates and CSS animations

Sid — Tue, 12 Mar 2019 03:57:51 +0000

I wrote this post for my newsletter, sign up here to get emails like these every week.

Hi!

For my course on React Hooks, I have to make a bunch of animations for it to be interesting.

A few folks asked how do those animations work...

You'll be surprised at how easy it is with CSS.

First, let's break down our composition:

We have a bird and a pirate that's hanging from the bird
They enter together from the right side of the screen
After reaching half way, the bird drops the pirate and leaves the screen from the left
The pirate falls to the bottom of the screen

Step #1: Characters

<div class="bird"></div>
<div class="pirate"></div>

.bird {
  background-image: url('./bird.png');
}
.pirate {
  background-image: url('./pirate-hanging.png');
}

With some hit and trial, we can position the pirate at exactly the right spot.

.pirate {
  top: 27px;
  margin-left: 49px;
}

We need another image for the pirate in his falling state. Because the image is a vector image (SVG), we can modify it to get the right posture. (I used sketch, but you do this in any image editor)

Okay, now that we have the graphics ready, let's think about the choreography.

Step #2: Choreography

Before we write any code, it's useful to write down the different steps of the animation.

t = 0     1     2     3     4     5         6     7     8     9
    ←---------  enter  --------⇥  ←  pause ⇥  ←----- exit ----⇥

1: 0s - 5s : bird: fly in + pirate: fly in
2: 5s - 6s : pause
3: 6s - 9s : bird: fly out + pirate: fall

Let's start with the bird flying in.

We want the bird to come in from outside the screen to the middle. We can attach the same animation to the pirate because he is hanging to the bird for this part.

Shout out to my friend Andres who helped me improve this article. He pointed out that animating position produces a repaint on every keyframe and using translation is way more performant. You should follow Andres on twitter, he's a CSS wizard.

.bird {
  animation: bird-enter 5s ease-out;
}
.pirate {
  animation: bird-enter 5s ease-out;
}

@keyframes bird-enter {
  from {
    /* right end of the screen */
    transform: translateX(100vw);
  }
  to {
    /* half way */
    transform: translateX(50vw);
  }
}

Looking good!

By default, the characters will reposition snap to their default position after the animation is finished. That's because CSS animations do not affect the element before the first keyframe is played or after the last keyframe is played.

We can use the property animation-fill-mode to override this behavior:

.bird .pirate {
  animation-fill-mode: forwards;
}

forwards will make the element stay in the same position as the final keyframe.

Alright, let's talk about the exit.

An element can have multiple animations applied to it.

.bird {
  /*         ↓ enter animation       ↓ exit animation   */
  animation: bird-enter 5s ease-out, bird-exit 3s ease-in;
}

Both of these animations will start at the same time though. That's not good, we want the second animation (exit) to start some time after the first animation finishes (enter).

This is where the animation-delay property comes in. The delay for the exit animation should be the duration of the first animation + the pause we want to take between animations: 5 + 1 = 6s.

Because we have multiple animations, we need to specify the delay for each of the animation.

.bird {
  /*         ↓ enter animation       ↓ exit animation   */
  animation: bird-enter 5s ease-out, bird-exit 3s ease-in;
  animation-delay: 0s, 6s;
  /* 0s delay for the entry animation, 6s for the exit  */
}

@keyframes bird-exit {
  from {
    transform: translateX(50vw);
  }
  to {
    /* exit outside the frame */
    transform: translateX(-10vw);
  }
}

Sidenote: you can also write the above code with the animation shorthand, where the 4th argument is delay: `bird-exit 3s ease-in 6s`.

Okay, now let's talk about the pirate's exit. The timing is the same as the bird, but the animation is a little different. We want the pirate to fall down from it's original position to the bottom end of the screen.

.pirate {
  /*         ↓ enter animation       ↓ exit animation   */
  animation: bird-enter 5s ease-out, fall 3s ease-in;
  animation-delay: 0s, 6s;
  /* 0s delay for the entry animation, 6s for the exit  */
}

@keyframes fall {
  from {
    /* keep it's X position */
    transform: translateX(50vw);
  }
  to {
    /* keep X position, fall to the bottom end of the screen */
    transform: translateX(50vw) translateY(100vw);
  }
}

Okay that's a good start, but we also need to change the image.

We can attach a different class to the pirate element with javascript to have a different background image. But, we can also achieve this through css.

If we supply the new background-image to the element in the from and to of the animation, it will apply it for the whole duration.

To make the effect even better, let's rotate the pirate while he falls.

@keyframes fall {
  from {
    /* keep it's X position */
    transform: translateX(50vw);
    background-image: url('./pirate-falling.png') rotate(0deg);
  }
  to {
    /* keep X position, fall to the bottom end of the screen */
    transform: translateX(50vw) translateY(100vw) rotate(90deg);
    background-image: url('./pirate-falling.png');
  }
}

This is the combined result:

If we use the SVG version of the pirate instead of PNG, we can go really deep and animate each part of the pirate. Something like:

.pirate .hand {
  animation: raise-up 2s ease-in;
}

We don't have to, of course. A few lines of CSS keyframes combined together gave a pretty good result too!

If you want to experiment, here's a codepen link to this animation.

Hope that was useful on your journey

Sid

How to get a job without experience

Sid — Mon, 25 Feb 2019 09:36:33 +0000

I wrote this post for my newsletter, sign up here to get emails like these every week.

I had a conversation with someone on twitter last week, and I think their situation was very relatable.

I've been an Android Developer for the last 1.5 years and I'm trying to get into a web developer role.

The issue I'm facing is most companies don't seem to look at my web dev credentials, they keep pushing for an Android role.

I've heard the same story in multiple flavors.

I am a junior developer trying to get a senior role at a better company, but I don't have interesting work to show — Someone I met last month

I want to get a job in tech, but I don't have a Computer Science degree — me in 2012

This meme is probably overplayed at this point:

Here's you can beat the cycle:

1. Be specific on the kind of work you want

This sounds silly, but you have to know the kind of work you want first. "Better job" / "more money" are honest but not specific enough.

Better: I want a frontend developer role in a team that works with React.

2. Position yourself as an expert experienced in that field

I'm going to be honest here, if you don't have relevant experience, a company shouldn't hire you.

Put yourself in the shoes of a CTO or team lead, you're hiring developers for your team. Which one of these developers would you hire?

Dipti who has worked on the same technologies your team uses and can start being productive from day 1

OR

Rahul who has no relevant experience but is enthusiastic and a fast learner.

Rahul seems like a great guy but he's probably not going to get the job.

How do you position yourself as an experienced developer? Well, you actively seek experience.

Learn & Practice

This isn't a secret, you have to learn a skill before you can get paid for it.

However, just completing a course or reading a book does not qualify as skill. You have to practice it, like a lot. The best way I know to learn a skill properly is to build something with it.

I wrote about this all the way back in newsletter #2: The best way to learn
Build a few small applications/side projects

You don't have to have relevant projects at another company to prove you know your stuff. That is only a trust proxy for the interviewer to see that other people value your skills.

You can showcase your personal projects as well, in fact, in most cases, you can showcase your skills better in a personal project because you get to define the requirements.
Contribute to open source projects

Another way of showcasing your skills is to contribute to popular open source projects.

You don't have to make the next big MVC framework, consistent tiny fixes to an existing library shows that you know what you're doing and can work with other people.

And guess what, you will learn a lot in the process. Not sure where to start? Click here.
Share what you learn

The most underrated way to showcase your new skills is to share it with others.

Give a talk at your local meetup, write a blog post and submit it to a medium publication. Put that in your resume.

To give a good talk / write a good blog post, you will have to research and explain the concept clearly - which gives you an instant increase in credibility.

If you meet someone who can explain a concept in simple words, you immediately conclude they must be really smart. Nope, they just spent a lot of time refining their understanding.

In an interview from the past, my interviewer spent the entire time discussing a blog post I had mentioned on my resume. The interview went really well because it revolved around what I already knew!

But, I don't have enough knowledge to share it with others.

I hear you, that's fair. When you're learning something new, your confidence is low.

Here's the kicker though, you don't have to be an expert in a topic to teach it. In fact, you're chances of giving a good talk or writing a good article are higher if you just learned that topic.

When you have spend a few years on a technology, you get used to things. I have to constantly remind myself that something that's obvious to me is completely alien to the person who is seeing it for the first time.

If you're still not convinced, watch this video on the concept of Document, not Create.

3. Get referred

There's one fundamental thing you have to change about your job hunt: You need to stop applying.

I can't say it better than how Kyle Shevlin did:

Stop Trying to Win the Resume Lottery

There's this game that so many people play that I like to call the "resume lottery". People throw their resume and cover letter into a giant pile of other resumes and cover letters and hope and pray that somehow they stand out. It's nearly impossible to win this game. I mean that literally. According to Designing Your Life, a book I've been loving lately, their research suggests that playing the "resume lottery" has a success rate of about 5%. That's horrible!

Why is that percentage so low? Because as much as 80% of job openings never make it to a job board. When they do, they aren't always really open. Often, they have a candidate in mind that they've customized the opening to fit to appease HR. On top of this, according to a 2015 report, 52% of managers admitted to responding to fewer than half of people who applied for a position. What chance do you have of winning the "resume lottery" up against those odds?!

Try smarter, not harder.

You should read the entire post.

There is no better way to increase your chances of getting the job than getting a warm introduction.

When someone on the team vouches for you, you get a good first impression before you even enter the building.

But, I don't know anyone who could refer me

Yeah, that's the tricky part about referrals, you can't just ask a stranger to refer you, you have to earn it.

The good news is if you take the advice from step #2 above, you're giving people a good reason to refer you. You're not just asking for a favor, you're asking them to review your work and see if it they like it.

As a mega-introvert, I have hard time making new friends and (for lack of better words) expanding my network. But, being a regular at the local meetup and sharing knowledge has made it easier to meet new people because the conversations start with the topic of my talk instead of awkward introductions.

4. Deploy patience

Credibility takes time. People don't remember announcements, they notice consistency.

Don't just write one blog post and give up, write a bunch of blog posts. Give a few talks, fix a bunch of open source issues.

This might take a couple of months, but the reward at the end will be worth it! You don't want just any job, you want the perfect job for you.

The job hunt in itself is a long stressful process. Sometimes things don't work out even when you give it your best.

I once went for an interview which lasted the entire day. I met 5 different people and the interviews went well, I went home feeling great. Next day, I got a call from HR telling me the CEO didn't approve the team's budget to hire more people. 🤷

Trust the work you are putting in.

That's all, here are some articles for further reading:

Hope that was useful on your journey!

Sid

Compound.Components and Context

Sid — Mon, 18 Feb 2019 07:06:54 +0000

This post was sent on my newsletter a few weeks ago, just saying.

This is part of a series of posts about writing good components

Today, let's talk about forms.

You have probably read a bunch of articles about state management in forms, this isn't one of them. Instead, I'd like to talk about the design and API of forms.

There are a bunch of things happening here, but first let me show you the API.

<Form layout="label-on-left">
  <Form.Field label="Name">
    <TextInput type="text" placeholder="Enter your name" />
  </Form.Field>

  <Form.Field label="Email">
    <TextInput
      type="email"
      placeholder="email@domain.com"
    />
  </Form.Field>
</Form>

Let's look at each one of the components and break them down:

Form

It starts with a Form component which on the surface is a basic form element with a class attached. It renders whatever you put inside it.

function Form(props) {
  return <form className="form">{props.children}</form>
}

render(<Form layout="label-on-left">...</Form>)

It also accepts a layout prop, which is useful for use cases where you are short on space.

<Form layout="label-on-top">...</Form>

This changes how the labels are aligned (right to left) and how margins work.

The form doesn't control the width and margin of it's inner contents though. That's for the form field to take care of.

The Form does need to communicate this layout information down though.

The easiest thing to do would be to pass the layout in props, but because the contents of a form is dynamic (decided by the developer who uses this form), we can't control that.

This is where the context API comes in.

/* Create a new context */
const LayoutContext = React.createContext()

function Form(props) {
  /*
    Wrap the children in a context provider
    with the value based on props
  */
  return (
    <form className="form">
      <LayoutContext.Provider
        value={{ layout: props.layout }}
      >
        {props.children}
      </LayoutContext.Provider>
    </form>
  )
}

export default Form
export { LayoutContext }

Now a form field can consume this context and get the value of layout

Form Field

The FormField component adds a label before rendering whatever you put inside it (like a text input).

function Field(props) {
  return (
    <div className="form-field">
      <label {...props}>{props.label}</label>
      {props.children}
    </div>
  )
}

In addition to that, it adds a class for layout - which comes from the context we created in Form.

/* Get the layout consumer */
import { LayoutContext } from './form'

/*
  Use the consumer to get access to the
  context - it uses the render prop API

  We pass this as the class to the form field
*/
function Field(props) {
  return (
    <LayoutContext.Consumer>
      {context => (
        <div className={`form-field ${context.layout}`}>
          <label {...props}>{props.label}</label>
          {props.children}
        </div>
      )}
    </LayoutContext.Consumer>
  )
}

The useContext hook from React 16.8+ makes the syntax easier to understand

/* Get the layout consumer */
import { LayoutContext } from './form'

function Field(props) {
  /*
    Grab the context from the useContext hook
    which accepts the context variable as the input
  */
  const context = useContext(LayoutContext)

  return (
    <div className={`form-field ${context.layout}`}>
      <label {...props}>{props.label}</label>
      {props.children}
    </div>
  )
}

If you're curious, you can check the css here:

.form-field.label-on-left {
  max-width: 625px;
  display: flex;
  align-items: center; /* align vertically */
}
.form-field.label-on-left label {
  text-align: right;
  width: 175px;
  margin-right: 25px;
}

.form-field.label-on-top {
  width: 100%;
  display: block; /* instead of flex*/
}
.form-field.label-on-top label {
  text-align: left; /* instead of right */
  margin-bottom: 25px; /* instead of margin-right */
}

Form.Field?

The last detail I want to talk about is this awkward dot syntax for components.

Because the form Field is always used with a Form, it makes sense to group them together for the user.

One way to do that is to export it from the same file:

/* form.js */
import Field from './field'

function Form(props) {
  /* ... */
}
export default Form

export { Field }

Now, users can import them together:

import Form, { Field } from 'components/form'

render(
  <Form>
    <Field>...</Field>
  </Form>
)

We can make a tiny improvement by attaching the Field on the Form component itself.

/* form.js */
import Field from './field'

function Form(props) {
  /* ... */
}

Form.Field = Field
export default Form

This code works because React components are javascript objects, and you can add additional keys on this object.

What this means for the user is when they import Form, they get the Field automatically.

import Form from 'components/form'

render(
  <Form>
    <Form.Field>...</Form.Field>
  </Form>
)

I really like this API because it makes the connection between Form and Form.Field obvious.

Note: You have to move the context into a different file to avoid cyclic dependency loop.

The combination of the dot syntax and context makes our Form component smart while keeping it composable at the same time.

Hope that was helpful in your journey

Sid

Rethinking the component model with Hooks

Sid — Mon, 11 Feb 2019 05:11:50 +0000

This post was sent to my newsletter last week.

Thanks to Dan Abramov for reviewing it and suggesting improvements.

If you're a fan of React, you might have already heard that the release with Hooks (v16.8) is here.

I've been playing with the alpha version for a few weeks now and I really like it. The adoption hasn't been all rainbows and unicorns though.

Learning useState and useReducer was pretty straightforward and has improved how I handle state.

I wrote about useState in an earlier post. Here's the short version:

function Counter() {
  /*
    create a new state pair with useState,
    you can specify the initial value
    as an argument
  */
  const [count, setCount] = useState(0)

  /*
    create a function to increase this count
    you have access to the current count as it
    is a local variable.

    Calling setCount will trigger a re-render
    just like setState would.
  */
  function increase() {
    setCount(count + 1)
  }

  return (
    <div>
      {count}
      <button onClick={increase}>Increase</button>
    </div>
  )
}

However, I really struggled with the useEffect hook.

The Effect Hook lets you perform side effects in function components.

Side effects can mean anything from updating the document title to making an API request. Anything that happens outside your React render tree is a side effect for the component.

With classes, you would typically do this in componentDidMount. With hooks, it looks like this:

import React, { useState, useEffect } from 'react'

// username is passed in props
render(<UserProfile username="siddharthkp" />)

function UserProfile(props) {
  // create a new state pair with empty object as default
  const [user, setUser] = useState({})

  // create a pair for loading state
  const [loading, setLoading] = useState(false)

  // Similar to componentDidMount
  useEffect(function() {
    // set loading to true at start
    setLoading(true)

    // fetch the user's details
    // username is passed in props
    fetch('/get-user?username=' + props.username)
      .then(response => response.json())
      .then(user => {
        setUser(user) // set user in state
        setLoading(false) // set loading to false
      })
  })

  if (loading) return <div>Fetching user... </div>
  else return <div>Hi {user.name}</div>
}

This feels familiar. It looks like componentDidMount in a different suit.

Well, it doesn't have the same way. The above code has a bug!

Look at this preview, it's on an infinite loop of fetching user and re-rending it (and not just because it's a gif!)

componentDidMount is called after the component has mounted. It fires just once.

On the other hand, the effect inside useEffect is applied on every render by default.

This is a subtle shift in the mental model, we need to change how we think about the component lifecycle - instead of mount and update, we need to think in terms of renders and effects

useEffect lets us pass an optional argument - an array of dependencies that informs React when should the effect be re-applied. If none of the dependencies change, the effect will not be re-applied.

useEffect(function effect() {}, [dependencies])

Some folks find this annoying - it feels like something that was simple is now complex with no benefit.

The benefit of useEffect is that it replaces three different API methods (componentDidMount, componentDidUpdate and componentWillUnmount) and hence makes you think about all those scenarios from the start - first render, update or re-render and unmount.

In the above component, the component should fetch user details again when we want to show a different user's profile, i.e. when props.username changes.

With a class component, you would handle this with componentDidUpdate or getDerivedStateFromProps. This usually comes as an after thought and until then the component shows stale data.

With useEffect, you are forced to think about these use cases early on. We can pass props.username as the additional argument to useEffect.

useEffect(
  function() {
    setLoading(true) // set loading to true

    // fetch the user's details
    fetch('/get-user?username=' + props.username)
      .then(response => response.json())
      .then(user => {
        setUser(user) // set user in state
        setLoading(false) // set loading to false
      })
  },
  [props.username]
)

React will now keep track of props.username and re-apply the effect when it changes.

Let's talk about another kind of side effect: Event listeners.

I was trying to build a utility that shows you which keyboard button is pressed. Adding a listener on window to listen to keyboard events is a side effect.

Step 1: Add event listener in effect

function KeyDebugger(props) {
  const [key, setKey] = useState(null)

  function handleKeyDown(event) {
    setKey(event.key) // set key in state
  }

  useEffect(function() {
    // attach event listener
    window.addEventListener('keydown', handleKeyDown)
  })

  return <div>Last key hit was: {key}</div>
}

This looks similar to the previous example.

This effect will be applied on every render and we will end up with multiple event listeners that fire on the same event. This can lead to unexpected behavior and eventually a memory leak!

Step 2: Clean up phase

useEffect gives us a way of cleaning up our listeners.

If we return a function from the effect, React will run it before re-applying the effect.

function KeyDebugger(props) {
  const [key, setKey] = useState(null)

  function handleKeyDown(event) {
    setKey(event.key)
  }

  useEffect(function() {
    window.addEventListener('keydown', handleKeyDown)

    return function cleanup() {
      // remove the event listener we had attached
      window.removeEventListener('keydown', handleKeyDown)
    }
  })

  return <div>Last key hit was: {key}</div>
}

Note: In addition to running before re-applying an effect, the cleanup function is also called when the component unmounts.

Much better. We can make one more optimisation.

Step 3: Add dependencies for re-applying effect

Remember: If we don't pass dependencies, it will run on every render.

In this case, we only need to apply the effect once, i.e. attach event listener on window once.

Unless the listener itself changes, of course! We should add the listener handleKeyDown as the only dependency here.

function KeyDebugger(props) {
  const [key, setKey] = useState(null)

  function handleKeyDown(event) {
    setKey(event.key)
  }

  useEffect(
    function() {
      window.addEventListener('keydown', handleKeyDown)

      return function cleanup() {
        window.removeEventListener('keydown', handleKeyDown)
      }
    },
    [handleKeyDown]
  )

  return <div>Last key hit was: {key}</div>
}

The dependencies are a powerful hint.

no dependencies: apply the effect on every render
[]: only apply on first render
[props.username]: apply when the variable changes

We can even abstract this effect out into a custom hook with cleanup baked in. This makes our component worry about one less thing.

function KeyDebugger(props) {
  const [key, setKey] = useState(null)

  function handleKeyDown(event) {
    setKey(event.key)
  }

  useEventListener('keydown', handleKeyDown)

  return <div>Last key hit was: {key}</div>
}

// re-usable event listener hook with cleanup
function useEventListener(eventName, callback) {
  useEffect(function() {
    window.addEventListener(eventName, callback)

    return function cleanup() {
      window.removeEventListener(eventName, callback)
    }
  }, [])
}

Note: `useEventListener` as defined above works for our example, but is not the complete implementation. If you're curious what a robust version would look like, see this repo.

Let's add one more feature to our KeyDebugger. After a second, the key should disappear until another key is pressed.

That's just a setTimeout, should be easy right?

In handleKeyDown, we can unset the key after a delay of a second. And as responsible developers, we will also clear the timeout in the cleanup function.

function KeyDebugger(props) {
  const [key, setKey] = useState(null)
  let timeout

  function handleKeyDown(event) {
    setKey(event.key)

    timeout = setTimeout(function() {
      setKey(null) // reset key
    }, 1000)
  }

  useEffect(function() {
    window.addEventListener('keydown', handleKeyDown)

    return function cleanup() {
      window.removeEventListener('keydown', handleKeyDown)
      clearTimeout(timeout) // additional cleanup task
    }
  }, [])

  return <div>Last key hit was: {key}</div>
}

This code has become a little more complex than before, thanks to the two side effects happening in the same effect - setTimeout nested within a keydown listener. This makes the changes harder to keep track of.

Because the two effects are nested, we couldn't reap the benefits of our custom hook as well. One way to simplify this code is to separate them into their own respective hooks.

Sidenote: There is a very subtle bug in the above code which is difficult to surface - Because timeout is not cleared when `key` changes, old callbacks will continue to be called which can lead to bugs.

function KeyDebugger(props) {
  const [key, setKey] = useState(null)

  function handleKeyDown(event) {
    setKey(event.key)
  }

  // keyboard event effect
  useEventListener('keydown', handleKeyDown)

  // timeout effect
  useEffect(
    function() {
      let timeout = setTimeout(function() {
        setKey(null)
      }, 1000)

      return function cleanup() {
        clearTimeout(timeout)
      }
    },
    [key]
  )

  return <div>Last key hit was: {key}</div>
}

By creating two different effects, we are able to keep the logic separate (easier to track) and define different dependencies for each effect. If we want, we can extract the timeout effect into a custom hook as well - useTimeout.

Sidenote: Because this component runs cleanup on every `key` change, it does not have the sidenote bug from before.

I know it sounds difficult at first, but I promise it will become easy with a little practice.

Hope that was useful in your journey.

Sid

P.S. I'm working on a React Hooks course - Learn React Hooks by building a game. I really believe it is going to be amazing.

Visit react.games to watch a preview of the course and drop your email to get a discount when it launches (March 15).

Don't create conflicting props

Sid — Thu, 10 Jan 2019 10:04:11 +0000

This is part of a series of posts about writing component API for great developer experience.

This post was originally posted on my newsletter a few weeks ago, just saying.

This is one of the easier ones:

We have a button here:

<Button>Click me</Button>

You probably also need a primary button to serve as your main action on a page. I used to like shaping the API just like you would say it - "Give me a primary button"

<Button>Click me</Button>
<Button primary>Click me</Button>

So pretty.

Now, as it goes with buttons, you probably need a few more. Here's what the props table ends up looking like:

name	description	type	default
`primary`	used to indicate the main action	`boolean`	false
`secondary`	used for actions which are less important	`boolean`	false
`destructive`	indicate that the user should be cautious, example: delete	`boolean`	false
`link`	used to style button similarly to a hyperlink	`boolean`	false

There are multiple props that can be used to change the appearance of the button. What is the expected outcome if someone uses them together?

<Button primary destructive>
  Click me
</Button>

Will one of them win, which one? Is it dependent on the order?

I would always ask: Why would someone write that? Is this even a real use case - "Give me a primary destructive button"?

Most of the times, this would be by mistake. But, if the developers have to ask questions like the ones above, it's probably not a good API.

As someone who is deciding the API, it's your job to:

minimise mistakes
minimise confusions around the API

So here's tip #1 for you: Don't create conflicting props

We can fix our above code pretty easily by using one prop which allows a list of options: appearance

<Button appearance="default">Click me</Button>
<Button appearance="primary">Click me</Button>
<Button appearance="destructive">Click me</Button>

We can add a list of supported appearance using prop-types.

Button.PropTypes = {
  appearance: PropTypes.oneOf(['default', 'primary', 'secondary', 'link', 'destructive'])
}

Now, even if the developer makes a mistake, they will get a helpful warning on their developer tools.

<Button appearance="danger">Click me</Button>

Warning: Failed prop type:
Invalid prop `appearance` of value `danger` supplied to `Button`,
expected one of `["default","primary","secondary","link","destructive"]`
in Button

This tip is pretty easy to implement, but will make your API a lot easier to use (and maintain).

Hope this was helpful on your journey

Sid

Give names to behaviors not interactions

Sid — Thu, 03 Jan 2019 12:48:17 +0000

When it comes to React components, props are the API that developers consume. A good API should be obvious, something the developer can guess. You want to make it easier for the developer to implement their feature and move on.

This is valid not just for developers creating component libraries, but also for developers building applications. Your team mates have to use the component API you create.

After consuming a bunch of articles + talks and doing an inventory of all the props we have in cosmos, I've come up a few guidelines.

Here's one of them:

This post was originally posted on my newsletter a few weeks ago, just saying.

We have this Switch component that accepts a prop, let's call it something for now.

A developer using our component can pass a function and we'll call it when the value changes.

<Switch something={fn} />

React gives us the freedom to call the prop whatever we want - handler / clickHandler / onClick / onToggle etc.

It has become sort of a popular convention to start your event handlers with an 'on' like onClick. This is because the HTML spec has a bunch of handlers that follow this convention already: onkeydown, onchange, onclick, etc.

Reusing an already existing convention is a great idea, your developers don't have to learn a new thing.

Okay, how about onClick?

<Switch onClick={fn} />

I'm not a big fan of the onClick handler here because it assumes that a mouse click is the only way to interact with this component.

Users on a mobile device would tap the switch with their finger or drag it to the right. Users with visual impairment will use it with a screen reader and keyboard keyPress.

As a developer using this component, I don't want to think about how end users interact with this component. I just want to attach a function that is called when the value changes.

Let's use a interaction agnostic API:

<Switch onToggle={fn} />

That makes sense, right? The switch toggles between it's two values.

Inside the component, you might want to proxy all possible interactions to the same function

function Switch(props) {
  return (
    <div
      className="switch"
      /* click for mouse users */
      onClick={props.onToggle}
      onKeyDown={function(event) {
        /* if the enter key is hit, call event handler */
        if (event.key === 'Enter') props.onToggle(event)
      }}
      onDrag={function(event) {
        /* pseudo code */
        if (event.toElement === rightSide) props.onToggle(event)
      }}
    />
  )
}

We've internalised all the implementation detail to expose a nice API for our users (developers).

Now, let's talk about a component hopefully all of us can agree on - a text input.

<TextInput />

HTML has an onchange attribute, the React docs use onChange in their examples as well. There seems to be consensus around this.

<TextInput onChange={fn} />

Easy peasy.

Now, let's put both these components together.

<TextInput onChange={fn} />
<Switch    onToggle={fn} />

Notice something odd?

Even though both the components need similar behavior, the prop is named differently. The props are perfect for their respective component, but when you look at all your components together, it's very inconsistent.

What this means for developer experience is that you always have to check what the prop is called before using it. Not ideal.

So, here's tip #2 for you: Aim for consistent props across components. The same behaviour should have the same prop across components.

This tip can also be phrased as Aim for a minimal API surface area. You should limit the amount of API a developer has to learn before they can start being productive.

That's a beautiful way to put it, all credit goes to Sebastian Markbåge. (I've linked his talk at the end of this post)

The way to implement this tip is to pick one prop and use it across all your components. From the two props we have in our example onChange is also in the HTML spec, so some developers might have already heard of it.

<TextInput onChange={fn} />
<Switch    onChange={fn} />
<Select    onChange={fn} />
// etc.

The consistency across components and the resulting ease of learning your API outweighs having the perfect prop for an individual component.

Made it till here? Great! Here's some bonus content for you.

Let's talk about that function signature for a minute.

<TextInput onChange={fn} />

An onChange event handler (fn in the above example), receives one argument - event.

It is triggered on each change to the input. You can get a bunch of useful information from this event

function fn(event) {
  console.log(event.target) // input element
  console.log(event.target.value) // text inside the input element
  console.log(event.which) // which keyboard key was hit
}

I assume most developers would be interested in event.target.value, so that they can use it for some other task - setting in state, submitting a form, etc.

In the case of our custom Switch component, every action exposes a different event. This event will have different properties for a click event and a drag event. How we make sure the API is consistent?

We can manually set event.target.value for every event:

function Switch(props) {
  /* custom handler */
  const fireHandler = event => {
    const newValue = !oldValue

    /* consistent property that devs can rely on: */
    event.target.value = newValue

    /* fire the handler from props */
    props.onChange(event)
  }

  return (
    <div
      className="switch"
      /* click for mouse users */
      onClick={fireHandler}
      onKeyDown={function(event) {
        if (event.key === 'Enter') fireHandler(event)
      }}
      onDrag={function(event) {
        if (event.toElement === rightSide) fireHandler(event)
      }}
    />
  )
}

Watch Sebastian's talk if you want to learn more about this concept: Minimal API Surface Area

Hope this was helpful on your journey

Sid

That was part of an ongoing series. If you enjoyed this, there's more where that came from 😉

DEV Community: Sid

So you want to start a blog

Why do we keep talking about CSS-in-JS?

The promise of CSS-in-JS

The next wave of CSS-in-JS libraries

React.lazy API in 60 seconds (Code-Splitting with Suspense)

Lessons learned from starting a small conference

*well, we kind of did. Pavithra was already in town from Australia.

Week of April 02 - Top 3 React articles from around the web

1. How to Avoid the Boolean Trap When Designing React Components by Filip Danić

2. Building a Componentized and Reusable Scroll to Top Feature in React by Sarah Sweat

3. react-frontload (library) by Dave Williams

The best time to write tests

Pirates and CSS animations

Step #1: Characters

Step #2: Choreography

Sidenote: you can also write the above code with the animation shorthand, where the 4th argument is delay: bird-exit 3s ease-in 6s.

How to get a job without experience

1. Be specific on the kind of work you want

2. Position yourself as an expert experienced in that field

3. Get referred

4. Deploy patience

Compound.Components and Context

Form

Form Field

Form.Field?

Note: You have to move the context into a different file to avoid cyclic dependency loop.

Rethinking the component model with Hooks

Step 1: Add event listener in effect

Step 2: Clean up phase

Note: In addition to running before re-applying an effect, the cleanup function is also called when the component unmounts.

Step 3: Add dependencies for re-applying effect

Note: useEventListener as defined above works for our example, but is not the complete implementation. If you're curious what a robust version would look like, see this repo.

Sidenote: There is a very subtle bug in the above code which is difficult to surface - Because timeout is not cleared when key changes, old callbacks will continue to be called which can lead to bugs.

Sidenote: Because this component runs cleanup on every key change, it does not have the sidenote bug from before.

Don't create conflicting props

Give names to behaviors not interactions

Sidenote: you can also write the above code with the animation shorthand, where the 4th argument is delay: `bird-exit 3s ease-in 6s`.

Note: `useEventListener` as defined above works for our example, but is not the complete implementation. If you're curious what a robust version would look like, see this repo.

Sidenote: There is a very subtle bug in the above code which is difficult to surface - Because timeout is not cleared when `key` changes, old callbacks will continue to be called which can lead to bugs.

Sidenote: Because this component runs cleanup on every `key` change, it does not have the sidenote bug from before.