DEV Community: Naina Razafindrabiby

What is the new Next.js Image Component?

Naina Razafindrabiby — Mon, 08 Mar 2021 00:00:00 +0000

One of the new features of Next.js 10 I really like is the image component. It simplifies how we load responsive, optimized images in our site.

Responsive Images

It is important to have different sizes of images for your website. If users are viewing your website on a mobile device, will you show them an image that is 1000px wide? Or if they are on a desktop device, will you show them a 200px wide image?

You need to load the appropriate image depending on the screen size and resolutions.

To make images responsive using the img tag, you would usually do something like this.

<img src="small.jpg" srcset="medium.jpg 1000w, large.jpg 2000w" alt="my-image">

The srcset attribute figures out which of the images is best for the browser resolution, but you need to have different image sizes.

When you use Next.js image component, images are resized and optimized on the fly. Images are responsive by default. No need to have different images for different sizes and resolutions.

Images are also served in webp format (if the browser supports it) — modern image format that supports superior lossless compression of images.

How to use it

You need to have Next.js 10 to be able to use the image component.

import Image from 'next/image';

export const Profile = () => (
  <Image src="/assets/profile-pic.jpg" alt="my picture" width={1200} height={900} />
);

export default Profile;

The src, width, and height props are required. If you don't pass the width and height props, you will have to set the layout prop to fill.

<Image src="/assets/profile-pic.jpg" alt="my picture" width={1200} height={900} layout="fill" />

There are 4 possible layouts with the image component.

fixed — no responsiveness with the image.
intrinsic(the default) — The image will scale the dimensions down for smaller viewports but maintain the original dimensions for larger viewports.
responsive — The image will scale the dimensions down for smaller viewports and scale up for larger viewports.
fill — The image will stretch both width and height to the dimensions of the parent element.

For a full list of props that the component accepts, you can check the docs.

Faster websites with images

The image component was built with optimization of images in mind.

Not so long ago, I have worked with a website of a friend that loaded multiple images in the homepage. When I opened the page for the first time, I was surprised that it took so long to open the home page (a very simple page). The most annoying part was that when I opened it on my phone, my phone would sometimes freeze.

When I checked the network tab, I saw that the main culprit was the images.

That's a whole lof of unoptimized images 😲. The files are huge and they are loaded even if they are not yet in the viewport.

After refactoring the code to use the image component of Next.js, the load time of the page has considerably improved. The images are now only loaded when it reaches the viewport and the format is in webp. The sizes are also small compared to the original size (a huge difference).

Next.js image component lazy loads images by default.

Styling

In order to style the image component, you have to wrap it with an outer div and apply the styles on the outer div.

<div className="image-wrapper">
  <Image src="/assets/profile-pic.jpg" alt="my picture" width={1200} height={900} layout="fill" />
</div>

Conclusion

My experience working with the image component is amazing so far. I really like this new feature because it simplifies my work as a developer to create responsive, optimized images. Images are part of any app or website, and if they are not optimized, they could destroy the whole user experience.

By using the image component, you could easily create an image that is responsive and optimized without doing a lot of work. So, use it in your Next project 😉.

Year 2020 in Review

Naina Razafindrabiby — Mon, 28 Dec 2020 00:00:00 +0000

We have a couple of days left before 2020 is gone. In this post I want to share some of the things that has happened to me during the year.

Blog

One of the goals I set this year was to create an online presence through a blog. My main motivation was to actually solidify what I already know by sharing, and also learn something new things. By writing tutorials and articles, I am forced to deeply learn about a topic and explain it to others in simple language.

In early February, I started creating my personal website where would be writing my articles. Then in March 11, I published my first article. Yes!! 😎 I was so happy.

I tried to write an article every week, but you know... , as what happens to many new bloggers, after just a month, my motivation kinda dried up. Around April, I paused a bit from writing and rewrote my blog from Next.js to Gatsby. I completely redesigned my site on how it looks and feel (what you are seeing right now). I was trying to learn Gatsby at that time, so why not apply what I learn, right?

After redoing my site, I resumed writing again, writing one article every week. That pace lasted for about two months before I got busy again. But instead of giving up with what I had already started, I decided that I would write an article at least once a month.

Now I have 17 articles (including this one) written this year. Although I initially planned to write 20 articles, having 17 out of 20 is already a great achievement for me, and I will definitely continue to write more in the coming year.

An article ranked number 1 in Google

One of my proudest achievement this year is that one of my articles ranked number 1 in Google search. It is about on how to create an accessible React modal using TypeScript.

I honestly didn't expect this to rank number 1, especially with the number of great articles already written about it. It is also one of my longest article, which was a pain to write. I still remember telling myself (at that time) to just write about something else that is shorter and simpler. Maybe if I did, I wouldn't have made this achievement. But my perseverance paid off 🙂.

Some of my other articles are also ranking well in Google. If there is one skill I truly learned this year, I think that would be SEO. I think I progressed from zero knowledge to a somehow intermediate/advance level.

First times

The Covid-19 pandemic has indeed brought many bad things, but one good thing I got from this pandemic was that I was able to work remotely full time. I had always dreamed of working remotely, and it has finally happened. I enjoyed it, and I felt I was more productive. I had more time because I didn't have to travel to work (which takes at least an hour everyday). Of course I also faced some downsides, like feeling lonely at times and communication was sometimes harder. But overall I liked it and would love to work remotely again.

2020 is the year I blogged for the first time. It was actually a scary thought for me in the beginning. What will I write about? Will people read my articles? What if someone better than me reads my blog? All those questions crossed my mind. I'm not also that great of a writer 😅. But after starting and continually writing, it got easier.

On a personal life, 2020 is also the year in which I attended a wedding for the first time 😲. Hmmm, still thinking how has that happened 🤔

Things I want to learn in 2021

Here are some items I want to learn in 2021.

Design Patterns
Design Systems
Tailwind CSS
Intersection Observer API

Conclusion

2020 is indeed not like any other year before, but it not all bad as most people say. If the pandemic left you the same, then you have missed a big opportunity to level up. I have learned many new things, and I have also tried many things I have never done before.

There is joke I have seen somewhere, saying, "What is one thing that has brought innovation to your company? Covid-19." 😂 I think this is true. The pandemic caused all of us to change in one way or another.

Let us hope 2021 will be better.

Test Driven Development (TDD) With React Testing Library

Naina Razafindrabiby — Wed, 14 Oct 2020 00:00:00 +0000

In this tutorial, we're gonna learn how to test React apps with react-testing-library by following a Test Driven Development (TDD) approach.

Testing your app is very important. In the software that you write, you wanna make sure that when you add a feature or refactor code, you don't break anything that has already been working. It could be time consuming to manually test everything again when you add or remove code. It could also be annoying to the user if a feature was working before and after adding a new feature, the previous feature is no longer working. To save us developers of all those troubles, we need to write automated tests.

We are going to build a Todo app. The user should be able to add, remove, and check off a todo item. This is how are final app will look like.

If you just want to read but just need the code, here is the github repo. Here is also a codesandbox you can test and play around. Note that at the time of this writing, the tests in codesandbox are not working, not because of the code itself but because of the codesandbox environment.

Prerequisite

To follow this tutorial, I assume you already know React. You know how to use the basic React hooks (useState and useEffect). You are also know HTML, CSS, and are familiar with ES6 features and syntax.

What is TDD

Test Driven Development or TDD is an approach in software development where we first write the tests before writing the actual code. This results in a better code quality, higher test coverage, and better software. There are three steps to do TDD.

First, you write a code that fails. This ensures that you avoid false positives. (RED)
Next, you write the minimum code to make the test pass. (GREEN)
Finally, you refactor to improve the existing implementation. (REFACTOR)

What is react-testing-library

There are many tools out there to test React apps, with Enzyme being one of the popular options. But in this tutorial, we are going to use react-testing-library. React-testing-library is like a wrapper of DOM Testing Library for testing React components. The DOM Testing Library is a simple, lightweight, open source, library that provides API for querying and interacting with DOM nodes. Besides React, the DOM Testing Library has also been used to create other wrappers for other frameworks, like Angular, Vue, and Svelte.

Why use react-testing-library instead of Enzyme? I really like the philosophy behind the DOM testing library.

The more your tests resemble the way your software is used, the more confidence they can give you.

This means that our tests should interact with our app just like a real user would do. In our Todo List app, a user would have to type in an input, and click the add button to add the item. Our test should also interact with the app in a similar way: type a todo item in the input, and click the button to add the item. Then we verify that the new item has actually been added. With react testing library, this not hard to achieve.

React-testing-library also prevents us from testing implementation details of the app. The implementation details are things that users would not normally see or use. It is only known to the developers (ex. the state of your app). When you are using enzyme, you are more likely to be testing these implementation details. If you test the implementation details, your tests will break if you change/refactor the code. This is something we want to avoid.

If you want to read more about the problems with testing implementation details, here is a nice post written by Kent Dodds (Testing implementation details).

Setup

We are going to create a new React app with create-react-app.

create-react-app demo-tdd
cd demo-tdd
yarn start

Then we need to install the libraries we need to test React components.

npm i --save-dev @testing-library/jest-dom @testing-library/react @testing-library/user-event

We installed 3 different libraries.

@testing-library/jest-dom. We are going to use this to make assertions about the state of the DOM using custom jest matchers for the DOM.
@testing-library/react. It provides APIs for us to work with React components in our tests.
@testing-library/user-event. It provides us with API to simulate real events(such as click) in the browser as the user interacts with the DOM. The @testing-library/react library already provides a fireEvent function to simulate events, but @testing-library/user-event provides a more advanced simulation.

If you are using the latest version of of Create React App, we also need to install jest-environment-jsdom-sixteen otherwise we get a "MutationObserver is not a constructor" error describe in this github issue.

We are using the latest CRA, so let's install this library.

npm i --save-dev jest-environment-jsdom-sixteen

Inside the package.json, change the test script tag to this.

"scripts": {
   ...
   "test": "react-scripts test --env=jest-environment-jsdom-sixteen",
   ...
}

Run the test.

yarn test

Displaying items in todo list

Let's now get into the real coding. So, as has been said, we are going to build a simple Todo app. The users should be able to see their Todo lists, and be able add and remove a todo item.

Failing test

Our first task is to create a todo list component that renders the list of todo items. Inside src/components/TodoList, we are going to create a TodoList component together with its test file.

import React from 'react';

const TodoList = ({ todos }) => <div></div>;

export default TodoList;

The TodoList component accepts a list of todos. Because we are first going to write the test before implementing the component, we are simply returning an empty div .

import React from 'react';
import '@testing-library/jest-dom';
import { render, screen } from '@testing-library/react';
import TodoList from './TodoList';
import mockData from '../../mockData';

describe('todo list test', () => {
  it('should show title of todos', () => {
    render(<TodoList todos={mockData} />);
    mockData.forEach((d) => expect(screen.getByText(d.title)).toBeInTheDocument());
  });
});

Here is our first test. We are testing whether our TodoList component shows us the title of our todo items. The @testing-library/react library provides us functions and objects like render and screen to interact with React components. As you might have already guessed, the render function is used to render a React component. We are rendering our TodoList component. Because it needs a list of todos, we pass a fake list of todos.

Here is a what the mockData contains inside src/mockData.js.

const mockData = [
  {
    userId: 1,
    id: 1,
    title: 'Eat breakfast',
    completed: false,
  },
  {
    userId: 1,
    id: 2,
    title: 'Do laundry',
    completed: false,
  },
  {
    userId: 1,
    id: 3,
    title: 'Take out the trash',
    completed: false,
  },
  {
    userId: 1,
    id: 4,
    title: 'Write a blog post',
    completed: true,
  },
  {
    userId: 1,
    id: 5,
    title: 'Go out for a walk',
    completed: false,
  },
];

export default mockData;

After rendering the component, we now need to make sure that we are actually seeing our items on the screen. Remember that the more our tests resemble the way our software is used, the more confidence we get? As a user, I expect to see my list of todos on the screen.

We need to query the DOM elements to know what is on the screen. React testing library provides a screen object that provides different methods for querying elements in the DOM. We can get elements by their text, role, label, testId, and other ways. You can find all the possible ways of querying DOM elements in the official docs.

So in this piece of code,

mockData.forEach((d) => expect(screen.getByText(d.title)).toBeInTheDocument());

what we're doing is that we are going through each todo list item and expect the title to be in the document (or page). We are using the screen.getByText() to get the element that has the title of our todo. Using Jest's expect function and custom matchers, we are able to validate that the title indeed exists in the document.

Making the test pass

If you run yarn test, you should get an error because we haven't implemented our component yet, and we are not seeing any of our todo items.

Okay, so let's implement the TodoList component to make the test pass.

import React from 'react';

const TodoList = ({ todos }) => (
  <div>
    {todos.map((t, i) => (
      <div key={i}>{t.title}</div>
    ))}
  </div>
);

export default TodoList;

Yes, after making the changes, our test pass.

Render TodoList component in App component

Let us render the TodoList component in the App component. Instead of using mock data for our list of todos, we are going get the data from a JSONPlaceholder - a nice fake REST API that we can play around with.

Let's change our App.js and App.test.js to the following.

import React, { useState, useEffect } from 'react';
import TodoList from './components/TodoList/TodoList';
import './App.css';

function App() {
  const [todos, setTodos] = useState([]);
  useEffect(() => {
    async function fetchData() {
      const result = await fetch('https://jsonplaceholder.typicode.com/todos').then((response) =>
        response.json()
      );
      setTodos(result.slice(0, 5));
    }
    fetchData();
  }, []);

  return (
    <div className="App">
      <h1 className="header">My todo list</h1>
      {<TodoList todos={todos} />}
    </div>
  );
}

export default App;


import React from 'react';
import { render } from '@testing-library/react';
import App from './App';

describe('<App /> tests', () => {
  it('renders <App />', () => {
    render(<App />);
  });
});

In App.js, we are just basically fetching our list of todos from "https://jsonplaceholder.typicode.com/todos" and we set out todos state with the result. We are only setting the first 5 result. Then we pass our todos to the <TodoList /> as prop.

As for the App.test.js, we are just making sure that <App /> renders. We are going to write more tests in here later.

If we check the browser, we should be able to see something like this.

However, our test in App.test.js fails. Hmmm, let's see why.

In the console, we get this.

It says that the json response of our fetch function in useEffect is invalid. But why? If we scroll further down the console, we see this.

When we are rendering our <App /> component in our test, we are making an asynchronous call with fetch API. However, before the response is received, the test finish running and the test environment is torn down. The fetch call is unable to finish properly, and we so we get an error.

So how do we solve this problem? Welcome to mocking.

Mocking fetch API calls

Mocking is creating a fake implementation of a function, method, or module. Mocking is important because we need fast tests. Making an API call will slow down our tests. Another reason is that calling APIs in a test can give inconsistent results. Sometimes it could fails because of network or server issues which we have no control.

To mock the fetch API, we are going to use jest-fetch-mock. First, let us install the library.

npm i --save-dev jest-fetch-mock

After installing, add the following to src/setupTests.js to enable mocks with jest-fetch-mock.

import fetchMock from 'jest-fetch-mock';

fetchMock.enableMocks();

Then in src/App.test.js, change the test to this.

import React from 'react';
import { render } from '@testing-library/react';
import App from './App';

beforeEach(() => {
  fetchMock.once(JSON.stringify(mockData));
});

describe('<App /> tests', () => {
  it('renders <App />', () => {
    render(<App />);
  });
});

Now, instead of calling the JSONPlaceholder API, we are just returning our mockData. fetchMock.once is a function of jest-fetch-mock that mocks each call of fetch independently. We put it inside beforeEach so that we don't have to repeat the same code over and over again.

If you run the test again, the test pass, but with a warning.

Warning: An update to App inside a test was not wrapped in act(...). When testing, code that causes React state updates should be wrapped into act(...):

Basically, this warning tells us that something we didn't expect happened in our component. We made an API call and when the response has returned, we updated our state and our component updated. In our test, we didn't take into consideration that our component will make an update, so React complained.

We need to wrap every interaction we make with the component with act to let React know that we are going to make an update. React-testing-library already wraps its APIs with act, but sometimes you may still have to fix it manually.

There are several ways to get rid of this error. Kent Dodds has a clear explanation of this error and solutions in his blog post. You can read further.

The way we are going to solve this problem is we are going to add a loading indicator when we are making API calls. When we are fetching the list of todos, we are going to show "loading" in our page, and when the fetch is successful, we are going to remove it and show the list.

In the src/App.js, make the following changes.

import React, { useState, useEffect } from 'react';
import TodoList from './components/TodoList/TodoList';
import './App.css';

function App() {
  const [todos, setTodos] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    async function fetchData() {
      const result = await fetch('https://jsonplaceholder.typicode.com/todos').then((response) =>
        response.json()
      );
      setTodos(result.slice(0, 5));
      setLoading(false);
    }
    fetchData();
  }, []);

  return (
    <div className="App">
      <h1 className="header">My todo list</h1>
      {loading ? 'Loading' : <TodoList todos={todos} />}
    </div>
  );
}

export default App;

And in src/App.test.js, we also make the following changes.

import { render, screen, waitForElementToBeRemoved } from '@testing-library/react';

// omitted other codes
it('renders <App />', async () => {
  render(<App />);
  await waitForElementToBeRemoved(() => screen.getByText(/loading/i));
});

We use the waitForElementToBeRemoved from react-testing-library to wait for an element to disappear from the DOM. It returns a promise, so we await it.

Now, when you run the test again, all tests pass without warnings.

Refactoring

Wouldn't it be better if we move the individual todo item to its own component? Let's try to improve the existing implementation of our TodoList component.

import React from 'react';
import TodoItem from '../TodoItem/TodoItem';

const TodoList = ({ todos }) => (
  <div>
    {todos.map((t, i) => (
      <TodoItem key={i} todo={t} />
    ))}
  </div>
);

export default TodoList;

Let's create the <TodoItem /> component.

import React from 'react';

const TodoItem = ({ todo }) => <div>{todo.title}</div>;
export default TodoItem;

This is the simplest implementation. Our <TodoItem /> accepts a todo item as prop and renders the title of the todo item. Then we render the component inside the <TodoList />.

And our test still passes. This is the best thing about automated tests. Even though we refactor our app, we can still be confident that we don't break anything.

So far we have followed the 3 steps to doing TDD: we created a failing test, implemented code to make test pass, and then refactor. Great!

Before moving on the next feature of our app, I'd like to briefly show a simple function to debug your tests in React testing library.

Debugging elements

In case you don't know what element to query in the DOM, or maybe your test fail because an element is not found, you can use the screen.debug() function to output the DOM elements. It is like the console.log() for react testing library.

It can help you write and debug your tests. If we add a screen.debug() to our test above, we would get something like this:

it('should show title of todos', () => {
  render(<TodoList todos={mockData} />);
  screen.debug();
});

Adding a new todo item

A Todo List app is not a Todo List app if we cannot add a new todo item, so let us add this capability in our app. Like what we did earlier, we are first going to write a test and then do the implementation.

Failing test

We are going to put the Add Todo button inside our <App /> component, so we are going to put the test inside App.test.js.

import React from 'react';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import App from './App';

// omitted beforeEach() ...
describe('<App /> tests', () => {
  // omitted first test...
  it('should add a todo item', async () => {
    fetchMock.once(
      JSON.stringify({
        userId: 3,
        id: Math.floor(Math.random() * 100) + 1,
        title: 'Do math homework',
        completed: false,
      })
    );

    render(<App />);
    await waitForElementToBeRemoved(() => screen.getByText(/loading/i));

    userEvent.type(screen.getByRole('textbox'), 'Do math homework');
    userEvent.click(screen.getByText(/Add new todo/i));
    await waitForElementToBeRemoved(() => screen.getByText(/saving/i));
    expect(screen.getByText(/Do math homework/i)).toBeInTheDocument();
  });
});

What's going on in our test?

First, we mock the fetch API calls. In our beforeEach() statement, we are already mocking the list of todos. But we also need to mock the POST request we are going to make when creating a new todo. So we call fetchMock.once again to mock the return data of the POST request.

Next, we render the App and wait for the "loading" text to disappear (as I have explained in the previous section).

Then we simulate a user typing into our input. We are using to userEvent.type() function to do that. It accepts 2 parameters: first is the input element, and second is the value to be typed.

Notice here we are using screen.getByRole to get the textbox in our document. It is another method for querying the DOM. For more information, you can always check the docs.

After the user has typed, we now simulate a click by using userEvent.click(). We find the element to click using screen.getByText().

Note: w_e are using a regular expression for the text. The "i" means ignore the case._

After clicking the button, we should see a "saving" text appear. We wait for it to disappear before we finally expect that the value the user typed is in the document (screen).

If you run the test, it should fail.

Making the test pass

Let's implement the test step-by-step to make it pass.

First, we're going to declare new state for the newTodo item and saving loader.

// other code above and below
const [newTodo, setNewTodo] = useState('');
const [saving, setSaving] = useState(false);

Then we're going to create an event handler for our input. When a user types in the input, we are going to set the newTodo to the value entered by the user. This is later going to be used when saving the data.

function onChange(e) {
  const value = e.target.value;
  setNewTodo(value);
}

We're also going to implement the add functionality. We are going to post our data to JSONPlaceholder API, and when the response is received, we are going to concat it to our list of todos.

function addTodo(e) {
  e.preventDefault();
  const value = {
    userId: 3,
    id: Math.floor(Math.random() * 10000) + 1,
    title: newTodo,
    completed: false,
  };

  setSaving(true);
  fetch('https://jsonplaceholder.typicode.com/todos', {
    method: 'POST',
    body: JSON.stringify(value),
    headers: {
      'Content-type': 'application/json; charset=UTF-8',
    },
  })
    .then((response) => response.json())
    .then((result) => {
      setTodos(todos.concat({ ...result, id: value.id }));
      setSaving(false);
    });
}

Notice here that the title of the new item is the todo state that we saved earlier. We are also setting the saving indicator to true before fetching and setting it to false after receiving the results.

Finally, we attach those handlers to the input and button. If it is saving,we display the "saving" indicator. Otherwise, we show the input and button.

<div className="add-todo-form">
  {saving ? (
    'Saving'
  ) : (
    <form onSubmit={addTodo}>
      <input type="text" onChange={onChange} />
      <button type="submit">Add new todo</button>
    </form>
  )}
</div>

If you run the test, it should all pass. The app should also work properly in the browser.

Here is our App.js file.

import React, { useState, useEffect } from 'react';
import TodoList from './components/TodoList/TodoList';
import './App.css';

function App() {
  const [todos, setTodos] = useState([]);
  const [loading, setLoading] = useState(true);
  const [newTodo, setNewTodo] = useState('');
  const [saving, setSaving] = useState(false);

  function onChange(e) {
    const value = e.target.value;
    setNewTodo(value);
  }

  function addTodo(e) {
    e.preventDefault();
    const value = {
      userId: 3,
      id: Math.floor(Math.random() * 10000) + 1,
      title: newTodo,
      completed: false,
    };

    setSaving(true);
    fetch('https://jsonplaceholder.typicode.com/todos', {
      method: 'POST',
      body: JSON.stringify(value),
      headers: {
        'Content-type': 'application/json; charset=UTF-8',
      },
    })
      .then((response) => response.json())
      .then((result) => {
        setTodos(todos.concat({ ...result, id: value.id }));
        setSaving(false);
      });
  }

  useEffect(() => {
    async function fetchData() {
      const result = await fetch('https://jsonplaceholder.typicode.com/todos').then((response) =>
        response.json()
      );
      setTodos(result.slice(0, 5));
      setLoading(false);
    }
    fetchData();
  }, []);

  return (
    <div className="App">
      <h1 className="header">My todo list</h1>
      {loading ? 'Loading' : <TodoList todos={todos} />}

      <div className="add-todo-form">
        {saving ? (
          'Saving'
        ) : (
          <form onSubmit={addTodo}>
            <input type="text" onChange={onChange} />
            <button type="submit">Add new todo</button>
          </form>
        )}
      </div>
    </div>
  );
}

export default App;

Removing a todo item

To implement this functionality, we must first go back to our TodoItem component and add the remove buttons for each todo item. When the user clicks the button, it is going to remove the clicked item.

Failing test for close button

We're going to write a test that the button is actually on the screen. Let's create a new test file inside src/components/TodoItem.

import React from 'react';
import '@testing-library/jest-dom';
import { render, screen } from '@testing-library/react';
import TodoItem from './TodoItem';
import mockData from '../../mockData';

describe('<TodoItem /> tests', () => {
  it('should render todo item properly', () => {
    render(<TodoItem todo={mockData[0]} />);
    expect(screen.queryByText(/eat breakfast/i)).toBeInTheDocument();
    expect(screen.getByTestId('close-btn-1')).toBeInTheDocument();
  });
});

There's nothing new here except for the screen.getByTestId. We are rendering a todoItem, passing the first item in our mockData as prop, and then expecting that the title of the item ('eat breakfast') and the close button to be on the screen.

We use the getByTestId query to get the close button. The way getByTestId query works is that we assign an element with data-testid attribute and we can query that element through the value of the attribute.

We use the getByTestId when we cannot query something with what is visible on the screen, like the text, role, or label. As the docs says, we should only use this if the other DOM queries don't work for our case.

Making the test pass for close button

Let us change our HTML markup in <TodoItem /> to this. Let us also added css file for some styling.

import React from 'react';
import styles from './TodoItem.module.css';

const TodoItem = ({ todo, removeHandler }) => (
  <div className={styles.itemContainer}>
    <div>{todo.title}</div>
    <button
      className={styles.closeBtn}
      data-testid={`close-btn-${todo.id}`}
      onClick={() => removeHandler(todo.id)}
    >
      X
    </button>
  </div>
);

export default TodoItem;

TodoItem.module.css

.itemContainer {
  display: flex;
  justify-content: space-between;
  margin: 15px 0;
}

.closeBtn {
  color: red;
  font-weight: 800;
}

.closeBtn:hover {
  cursor: pointer;
}

Here we have passed a removeHandler as prop to handle the click event. We are going to pass the id of the todo item so that we may know which item to delete. Notice we also have the data-testid attribute. This is going to be used by our test to query the span element.

Right now if you check the browser, the CSS is not properly centered. Let's change App.css to do this.

.App {
  width: 40%;
  margin: auto;
}

.header {
  text-align: center;
}

And now we have this.

Implementing the remove handler

At the moment if you click at the remove button, it's going to throw an error because we haven't implemented it yet. Let's go and implement it. Inside App.test.js, add the following test case.

it('remove todo from list', async () => {
  render(<App />);
  await waitForElementToBeRemoved(() => screen.getByText(/loading/i));
  userEvent.click(screen.getByTestId('close-btn-3'));
  expect(screen.queryByText(/Take out the trash/i)).not.toBeInTheDocument();
});

Again, nothing new in here. We render the app as usual, wait for the loading indicator to disappear, then click the 3rd remove button (we get the element through getByTestId), and then assert that the item in NOT in the document.

Inside App.js, let us add add a removeTodo() function and pass it down to our <TodoList /> then to <TodoItem /> .Our removeTodo is just going to filter our todos and set a new state.

// ...other codes
function removeTodo(id) {
  setTodos(todos.filter((t) => t.id !== id));
}

return (
  <div className="App">
    <h1 className="header">My todo list</h1>
    {loading ? 'Loading' : <TodoList todos={todos} removeHandler={removeTodo} />}

    <div className="add-todo-form">
      {saving ? (
        'Saving'
      ) : (
        <form onSubmit={addTodo}>
          <input type="text" onChange={onChange} />
          <button type="submit">Add new todo</button>
        </form>
      )}
    </div>
  </div>
);


const TodoList = ({ todos, removeHandler }) => (
  <div>
    {todos.map((t, i) => (
      <TodoItem key={i} todo={t} removeHandler={removeHandler} />
    ))}
  </div>
);

And now the remove functionality should work. The tests should also pass. Great!

Completing a todo item

The last thing I'd like us to implement is to allow the user to checkoff a todo item when he/she has completed a task.

In our TodoItem.test.js file, let us add the following test case.

// ...other test case above
it('should render todo item with checkbox.', () => {
  render(<TodoItem todo={mockData[0]} />);
  expect(screen.getByTestId('checkbox-1')).toBeInTheDocument();
  expect(screen.queryByText(/eat breakfast/i)).toBeInTheDocument();
});

You would probably already know by now what this does 😀 We are simply checking that the checkbox is on the screen.

In our TodoItem component, we are going to add a checkbox before each item. Change the HTML markup to this.

const TodoItem = ({ todo, removeHandler, updateTodo }) => (
  <div className={styles.itemContainer}>
    <div>
      <input
        type="checkbox"
        name={`checkbox-${todo.id}`}
        checked={todo.completed}
        data-testid={`checkbox-${todo.id}`}
        onChange={() => updateTodo(todo.id)}
      />
      <label
        htmlFor={`checkbox-${todo.id}`}
        onClick={() => updateTodo(todo.id)}
        className={todo.completed ? styles.completed : ''}
      >
        {todo.title}
      </label>
    </div>
    <button
      className={styles.closeBtn}
      data-testid={`close-btn-${todo.id}`}
      onClick={() => removeHandler(todo.id)}
    >
      X
    </button>
  </div>
);

We have changed the markup by adding a checkbox input and label containing the title of the todo item. The todo prop object has a property called completed. When it is true, we set the value of our checkbox to checked, and we add a completed class to the label (which we're gonna use for testing below). We also passed updateTodo handler to change the state of our checkbox.

In TodoItem.module.css, let's add the style for a completed item.

// ..other styles above
.completed {
  text-decoration: line-through;
}

Great. We're really almost done 😀. Now that we have added the checkbox and markup set up, we are going to implement updateTodo handler.

As usual, we are first going to add a test first. What are we going to expect if a user checks-off a todo item? As a user, I should see that the item is crossed out on the screen. I guess there's really no best way to do this than to check the css. It looks like we are testing an implementation detail, but the computer cannot see like us human that the item is actually crossed out 😅 So I guess checking if the css is applied will just be fine.

// other tests above
it('todo item should be crossed out after completing', async () => {
  render(<App />);
  await waitForElementToBeRemoved(() => screen.getByText(/loading/i));
  userEvent.click(screen.getByTestId('checkbox-1'));
  expect(screen.getByText(/eat breakfast/i)).toHaveClass('completed');
});

We use the toHaveClass matcher of Jest to know that the class has been applied to an element.

Inside App.js, we are going to add the updateTodo function and pass it to our TodoItem component.

// other code above
function updateTodo(id) {
  const newList = todos.map((todoItem) => {
    if (todoItem.id === id) {
      const updatedItem = { ...todoItem, completed: !todoItem.completed };
      return updatedItem;
    }
    return todoItem;
  });
  setTodos(newList);
}

return (
  <div className="App">
    <h1 className="header">My todo list</h1>
    {loading ? (
      'Loading'
    ) : (
      <TodoList todos={todos} removeHandler={removeTodo} updateTodo={updateTodo} />
    )}

    <div className="add-todo-form">
      {saving ? (
        'Saving'
      ) : (
        <form onSubmit={addTodo}>
          <input type="text" onChange={onChange} />
          <button type="submit">Add new todo</button>
        </form>
      )}
    </div>
  </div>
);


const TodoList = ({ todos, removeHandler, updateTodo }) => (
  <div>
    {todos.map((t, i) => (
      <TodoItem key={i} todo={t} removeHandler={removeHandler} updateTodo={updateTodo} />
    ))}
  </div>
);

Congrats 🎉! Our TodoList is finally complete. And it is fully tested. We have a total of 3 test suites and 7 tests cases in all. We can have confidence that if we refactor of change something, our app won't break.

Summary

This tutorial has been really long 😅. If you have followed up to this point, I wanna congratulate you.

We have built a complete Todo app. Along the way, we have learned how to write tests first before writing the implementation. We learned how to use react-testing-library to test our components based on how the user is going to user our app and not the implementation details. You can learn more about what the library can do in its official documentation. There are still many queries that we haven't used in this tutorial.

If you wanna play around with the code, I have created a github repo and a codesandbox. Check them out. At the time of this writing, the tests in codesandbox are not working. It is a problem with the codesandbox environment and not the code itself.

Nullish Coalescing and Optional Chaining Operator

Naina Razafindrabiby — Mon, 07 Sep 2020 00:00:00 +0000

ECMAScript 2020 has released many interesting features, and in this post I want to discuss two of the new features that I really like — the nullish coalescing operator and the optional chaining operator.

Nullish coalescing operator

Quoting from the MDN docs, it is

a logical operator that returns its right-hand side operand when its left-hand side operand is null or undefined, and otherwise returns its left-hand side operand.

It is denoted by a double question mark ?? . Here is an example.

undefined ?? 'Web design'; // Web design
null ?? 'Mansion'; // Mansion

In this example, the right-hand side value is returned because the left-hand side is null or undefined. But if the left-hand side operand has a value (as in the following example), the left-hand side value is returned.

'JavaScript Data Structures' ?? 'Web design'; // JavaScript Data Structures

How is it different from || operator

Unlike the OR operator, the nullish coalescing operator only looks for null or undefined values. If the value is a falsey value (besides null and undefined), the nullish coalescing operator will return the falsey value.

Here are the falsey values in JavaScript.

false
null
undefined
0
''
NaN

0 ?? 15; // 0
false ?? true; // false
'' ?? 'banana'; // ""

So when do you use the null coalescing operator over the OR operator? Here is a simple guideline on what to use. If you want to filter out falsey values, then you should probably use the OR operator. But if falsey values are valid default values to you, then you should probably use the nullish coalescing operator.

Chaining nullish coalescing operator

It is cool that you can actually chain the nullish coalescing operator, so this is completely valid.

null ?? undefined ?? 0 ?? 'nice'; // 0
null ?? '' ?? 'great'; // ''

You cannot, however, combine it with && or || operators. This will throw a Syntax error.

null || undefined ?? 'not working'

But if you wrap the || expression with a parethesis, it will work.

(null || undefined) ?? 'working';

Optional Chaining

This is my favorite new feature in ECMAScript 2020. Have you ever encountered a code like this?

const person = {
  address: {},
};

if (person.address && person.address.position && person.address.position.latitude) {
  // do something
}

Before accessing the latitude property, you first have to do a series of checks to make sure it actually exists, otherwise you will get an error Cannot read property 'latitude' of undefined. I frequently encounter code like this, and it can sometimes be pretty annoying.

Here is where optional chaining shines. We can check if the property exists by just using ?. after the property of an object. Let's refactor the code above.

if (person.address?.position?.latitude) {
  // do something
}

Now it is much shorter and cleaner. The optional chaining operator will check for us if the property exists. If the property doesn't exist it will just return undefined and not throw an error.

You can also use optional chaining with arrays and functions. Suppose you have an array of objects like this.

const persons = [
  {
    name: 'Peter',
  },
  {
    name: 'Jessica',
  },
];

If you try to access 3rd person name (which doesn't exist), it will throw an error.

persons[2].name; // Cannot read property 'name' of undefined

But if you use the optional chaining operator, it will just return undefined.

persons[2]?.name; // undefined

The same with functions (returns undefined if it doesn't exist)

persons[2]?.name.toLowerCase(); // undefined

Combining optional chaining with nullish coalescing operator

Because the optional chaining operator returns undefined if a property doesn't exit, we could use it together with the nullish coalescing operator to set default values.

const person = {
  address: {},
};

console.log(person?.address?.position ?? 'No address defined.'); // No address defined

Conclusion

JavaScript has immensely improved since ECMAScript 2015 and a lot of new features are being added to the language every year. It is no longer just a language you use for simple animations in the browser 😉

We have seen how to use the nullish coalescing and optional chaining operator. In summary, you can use the nullish coalescing operator if you want your default values to include falsey values. And if you are not sure whether an object has a certain property before accessing it, you can use the optional chaining operator to avoid a long series of check and Cannot read property error.

Thanks for reading! If this has helped you, kindly please share 😎

Intro to GraphQL and React using TypeScript

Naina Razafindrabiby — Wed, 26 Aug 2020 00:00:00 +0000

GraphQL is a modern way of requesting data from the server to the client. It is a query language that allows the client to describe the data it needs.

There are three characteristics of GraphQL that differentiates it from REST APIs. First , with GraphQL, you can get exactly what you need, nothing more or nothing less (under fetching or over fetching). You can request the exact piece data you need.

Second , you can get multiple data from different sources in just one single query. With REST API, you may need to make multiple request to get all the data.

Third , it uses a type system to describe what data can clients request.

In this tutorial, I will show you the basics of how to use GraphQL with React and TypeScript. We are going to use Apollo Client to consume GraphQL API. Apollo is a set of tools we can use to query and also set up a GraphQL server.

Query structure

The structure of a GraphQL query looks something like this.

query Countries {
  countries {
    name
    code
    capital
  }
}

The query keyword indicates the operation type. This means that the operation type is a query, which is equivalent to a GET request in REST. We can also have a mutation, which is for POST, PUT, PATCH, and DELETE in REST.

Countries is the name of the query, but we can also have an anonymous one (without a name).

query {
    countries {
        name
        code
        capital
    }
}

After the query, we now specify the fields that we want to get. Here, we are getting the list of countries, and for each country, we are getting its name, code, and capital.

There are many other things you can specify in a query, such as variables, fragments, and directives. If you want to dive dive deeper into the anatomy of a GraphQL query, check out this post. Anatomy of a graphql query

Setting up Apollo

As mentioned earlier, Apollo is a set of tools that makes is it easier for developers to work with GraphQL. We have the Apollo Client and the Apollo Server.

Apollo Client is what you use to consume GraphQL API, and it supports popular frontend frameworks such as React, Angular, Vue, and more. This is what we're gonna use in this tutorial together with React.

Apollo Server is what you use to set up a GraphQL server and send responses back to the client. In this post, we are not going to create our own server, but instead we are going to use a public GraphQL API for information about countries to demonstrate how to use GraphQL queries.

(https://github.com/trevorblades/countries)

So, to use Apollo Client with React, we first need to install all the necessary packages. I assume that you already have a TypeScript React project set up at this point 🙂

npm install @apollo/client graphql

After installation, we need to create a client. In the index.tsx file, copy the following piece of code.

import { ApolloClient, InMemoryCache } from '@apollo/client';

const client = new ApolloClient({
  uri: 'https://countries.trevorblades.com/',
  cache: new InMemoryCache(),
});

We are instantiating a new object from the ApolloClient class, and we are passing the options for our client in the constructor. The uri points to the url of the GraphQL server, and the cache is the caching strategy we're going to use with the client. InMemoryCache is the default mechanism provided by Apollo, and it's a good one to start with.

After creating a client, we now need to connect our React app to the client. We can do this by wrapping the <App /> component with the ApolloProvider.

import { ApolloClient, InMemoryCache, ApolloProvider } from '@apollo/client';

const client = new ApolloClient({
  uri: 'https://countries.trevorblades.com/',
  cache: new InMemoryCache(),
});

const App: FunctionComponent = () => <CountryList />;

render(
  <ApolloProvider client={client}>
    <App />
  </ApolloProvider>,
  document.getElementById('root')
);

We pass the an ApolloClient to the ApolloProvider as a prop. Any component nested in between the ApolloProvider can now perform GraphQL operations.

Making your first query

We are ready to do our first GraphQL query. The uri of the GraphQL server that our app is pointing to provides information about countries, capital, continent, and other information. So for our first query, we are going to create a <CountryList/> component that will list of all the countries around the world together with their capital city and continent.

We are going to create a new file called CountryList.tsx. The content of this file will be like this:

import React, { Fragment } from 'react';
import { useQuery, gql } from '@apollo/client';

interface Country {
  name: string;
  code: string;
  capital: string;
  continent: {
    name: string;
  };
}

interface CountryData {
  countries: Country[];
}

const COUNTRIES_QUERY = gql`
  query Countries {
    countries {
      name
      code
      capital
      continent {
        name
        code
      }
    }
  }
`;

const CountryList: FunctionComponent = () => {
  const { data, loading, error } = useQuery<CountryData>(COUNTRIES_QUERY);
  if (loading) {
    return <p>Loading...</p>;
  }
  const { countries } = data;

  return (
    <>
      {countries.map((c, i) => (
        <div key={i}>
          {c.name} - {c.capital} - {c.continent.name}
        </div>
      ))}
    </>
  );
};

export default CountryList;

We defined our GraphQL query in a constant called COUNTRIES_QUERY. It uses gql, a parser function that parses our plain string containing GraphQL code. In this query, we are requesting a list of countries, with their name, code, capital and continent. This is the nice thing about GraphQL because we can specify exactly what fields we need.

Then, inside the CountryList component, we use a custom React hook provided by Apollo to execute our query. The useQuery hook fetches the GraphQL query and returns a result that we can use in our UI.

The useQuery hook returns a data property (we destructured it) that basically contains the information we requested for. But it also returns a loading property, and an error property. Here, we are using the loading property to show a loading message while data is being fetched. You can console log the result of useQuery to see all the available properties returned.

The data property contains the list of countries, so we just map through the list and return the jsx containing the name, capital and continent of the country. Notice how we also typed the data returned by useQuery hook to be of type CountryData.

So yea, making a query is as simple as that 😉

Query with parameters

Let us say we only want to get European countries. How do we do that? GraphQL allows us pass variables in the query. It is like the query params in REST, but more powerful.

We can modify our query constant above to something like this.

const COUNTRIES_QUERY = gql`
  query Countries {
    countries(filter: { continent: { eq: "EU" } }) {
      name
      code
      capital
      continent {
        name
        code
      }
    }
  }
`;

Our GraphQL endpoint allows us to pass a filter object to filter the results. This is how the server was set up. What we pass here depends on your GraphQL endpoint. So here we are simply getting countries that have continent code equal to "EU". If you replace the constant above with this one, you will only get European countries in your list.

That is pretty static, because we hard-coded the filter, but we can also make it dynamic.

const COUNTRIES_QUERY = gql`
  query Counties($code: String) {
    countries(filter: { continent: { eq: $code } }) {
      name
      code
      capital
      continent {
        name
        code
      }
    }
  }
`;

The code we pass in the filter is now dynamic. The $code is of type string, and we use that value in the filter for countries.

To pass the actual value, we can change our useQuery hook to this.

const continentCode = 'EU';
const { data, loading } = useQuery<CountryData>(COUNTRIES_QUERY, {
  variables: {
    code: continentCode,
  },
});

The useQuery hook accepts a second argument as object, and that is where we pass our argument for the parameter in our query.

Here is the final code. Notice that we have also typed our query variables with CountryVariable interface.

import React, { Fragment } from 'react';
import { useQuery, gql } from '@apollo/client';

interface Country {
  name: string;
  code: string;
  capital: string;
  continent: {
    name: string;
  };
}

interface CountryData {
  countries: Country[];
}

interface CountryVariable {
  code: string;
}

const COUNTRIES_QUERY = gql`
  query Counties($code: String) {
    countries(filter: { continent: { eq: $code } }) {
      name
      code
      capital
      continent {
        name
      }
    }
  }
`;

const CountryList = () => {
  const continentCode = 'EU';
  const { data, loading } = useQuery<CountryData, CountryVariable>(COUNTRIES_QUERY, {
    variables: {
      code: continentCode,
    },
  });

  if (loading) return <p>Loading...</p>;
  const { countries } = data;

  return (
    <>
      {countries.map((c, i) => (
        <div key={i}>
          {c.name} - {c.capital} - {c.continent.name}
        </div>
      ))}
    </>
  );
};

export default CountryList;

Mutation

If you want to make a POST, PUT, PATCH, or DELETE http request, then you have to use GraphQL mutations. Since the GraphQL endpoint we are using doesn't have mutations, I'm just going to show you how it is done, but we won't be able to test it.

First, you have to create a mutation operation.

const ADD_COUNTRY_MUTATION = gql`
  mutation AddCountry($country: Country) {
    addCountry(country: $country) {
      name
      code
      capital
    }
  }
`;

We use the mutation keyword, and we pass the data (country) that we want to insert as an argument to the GraphQL operation. $country is of type Country (which is defined in your GraphQL schema in the server). After the operation is successful, we will return the name, code, and capital of the country.

Next, to actually execute the operation, we need to use the useMutation hook provided by Apollo client.

import { useMutation } from '@apollo/client';

interface Country {
  id: string;
  name: string;
  code: string;
  capital: string;
  continent: string;
}

interface FormData {
  country: Country;
}

const ADD_COUNTRY_MUTATION = gql`
  mutation AddCountry($country: Country) {
    addCountry(country: $country) {
      name
      code
      capital
    }
  }
`;

const CountryForm = () => {
  const dummyFormData: FormData = {
    id: 'FXJ32JD',
    code: 'FR',
    name: 'France',
    capital: 'Paris',
    continent: 'Europe',
  };

  const [addCountry, { data }] = useMutation<Country, FormData>(ADD_COUNTRY_MUTATION, {
    variables: {
      country: dummyFormData,
    },
  });

  return (
    <>
      <button onClick={addCountry}>Add new country</button>
    </>
  );
};

export default CountryForm;

Like the useQuery hook, useMutation accepts 2 arguments, the first one is the mutation operation, and the second one is an object that contains the variables to pass to the mutation. Our POST data is going to be passed as a variable in the second argument.

The useMutation hook doesn't immediately execute the query, but instead it returns to us an array that contains the mutation function. The first item in the array is the mutate function (as which we assign to addCountry), and the second item is the data that is returned. In the example, we are both destructuring the values (array destructuring). You can call the addCountry mutation function anytime to execute the query.

And that's it. Whether you want to perform a POST, PUT, or a DELETE, you basically follow the same thing.

Conclusion

This is a simple introduction to using queries and mutations with React and TypeScript. There's still a lot that you can learn, but knowing the basics will definitely help you continue with your learning. Maybe in a future post, I will also show how to setup a GraphQL server.

Feel free to play around with the code in this Stackblitz project.

Thanks for reading! If this has helped you, kindly please share 😎

How to Stay Up-To-Date as a Software Developer

Naina Razafindrabiby — Mon, 13 Jul 2020 00:00:00 +0000

If you are in the JavaScript world, I'm sure you have already heard of the phrase "JavaScript Fatigue". It seems that new opensource JavaScript tools and frameworks are being released everyday, and it causes new and seasoned developers to experience some kind of a fatigue when trying to keep up with all of them.

But the software industry is moving at a very high pace in general. We are always looking for ways to improve the experience developing applications (developer experience), but also reduce the time and complexity involved in delivering software. Software developers are students for life.

In this post, I want to share my ways of staying up to date in web development. Although the tips are directed more towards JavaScript developers and web development, developers using other languages will also find it helpful.

Why stay up to date

One of the main reason is to stay relevant in the job market. You will not remain in your current job forever. You might get fired, laid off, or come across a higher paying job. At some point in your career, you will have to move to another opportunity simply to improve yourself. If you only use old technology and do not want to learn new things, you will be left behind.

Another reason is to learn better ways of doing things. There might be a simpler way of achieving the task you have at hand. Someone may have already solved the problem, and you just have to follow his approach. Learn so that you can become more productive.

Not knowing everything

It is definitely ok not to know everything. It is perfectly fine not to learn every new shiny toy that comes out. You might go insane (hence JavaScript fatigue) if you do that.

If a new framework is released, I don't immediately go deep into learning it. I usually just get an overview of it, and know that it exists, but I don't invest much of my time learning it. I would give the framework some time to mature and get traction from other developers before getting serious with it.

I would also learn technologies that is only relevant to me. If I am a web developer, why would I try to learn tools and frameworks needed for Android development? That would be crazy, right?!

Tips for staying up to date

Newsletters

Subscribe to newsletters that are relevant to your career. If you are a JavaScript developer like me for example, subscribe to web development newsletters. Here are some of the newsletters I am subscribed to.

React Status. This is weekly newsletter (every Wednesday) containing updates on the framework, tutorials, tools, tips and stories on the framework.
Frontend Focus. This is a weekly newsletter (also every Wednesday) about HTML, CSS, browser features and updates, accessibility, and other frontend related stuffs.
JavaScript Weekly. Another weekly newsletter (every Friday) about JavaScript, toolings, tutorials, and also frameworks.

You can spend 30 minutes or an hour per week to read some of the articles in these newsletters.

Podcasts

I love podcasts. I listen to at least one or two podcasts every week. They are very convenient to me because I can listen to them when I'm walking to work or doing something else. Unlike newsletters, you won't find tutorials in podcasts. Instead, you get discussions, debates, and insights into technologies and tools.

Here are podcasts I subscribe to:

SyntaxFM. This is probably my favorite. Scott and Wes are very entertaining, and they give you the "tastiest, and hastiest" web development treat every week. They talk about JavaScript, HTML, CSS, web frameworks, career advice, and many other topics related to web development.
RealTalk JavaScript. I just started listening to this recently. John Papa, together with other hosts, talk about some of the challenges faced by web developers. They usually invite guests to share their experiences when developing web applications.
JavaScript Jabber. Podcast that is specifically dedicated to JavaScript. The episodes are about frontend, backend, coding practices, tools, environment, and many others.
React Podcast. If you are into React, listen to this podcast. The episodes covers interviews, conversations, and discussions with React developers. You'll learn a lot on what is going on in the React land.

Twitter

I mainly use Twitter as my tech news feed. I follow relevant people in the industry to learn about other developers' opinion on things. Of all the social media in the internet, I think Twitter is where most software developers hang out. I am surprised that I have learned many tips and tricks I didn't know before from Twitter.

You can use Twitter to share your ideas and thoughts to other developers. If you have a blog, you can also share your article. Who knows it might help someone in need.

Conferences

Attending a tech conference is still one of the activities I want to do in my career. Due to my current location and situation, it is hard for me to attend any conference, but if you get an opportunity to do so, please attend. It is an opportunity to network with great developers from around the world.

Attending a conference in person is very different from reading a blog tutorial, watching a video, or listening to a podcast. When you attend a conference, you can ask questions and interact with other developers.

Blogging

You may ask, "How will blogging help me stay up to date"? When you start a blog, you will have to find topics to write about. This will require you to do research, hence you teach yourself new things. You don't want to embarrass yourself by teaching outdated stuff.

I would also like to include in this section that it is also helpful to follow other developers' blog. You can subscribe to their newsletter. There are many awesome blogs out there with great content. Some of my favorites:

Tania Rascia

Kent Dodds

Robin Wieruch

Conclusion

Staying up to date with things is very important for software developers, but it is also though. By knowing how to stay relevant, you will be able to level up your career. The tips above are my ways of staying up to date. What about you?

Create an Accessible and Reusable React Modal (TypeScript)

Naina Razafindrabiby — Mon, 22 Jun 2020 00:00:00 +0000

Have you ever used a modal where you cannot interact with the modal using your keyboard? I don't know about you, but I find it annoying. I do not want to use my mouse every time I want to close a modal.

In this tutorial, I'm going to show you how to build an accessible, but also a reusable and responsive React modal using TypeScript and styled-components. We are going to follow the WAI-ARIA Practices set by W3C to make the modal accessible.

By the end of this tutorial, we will have a modal like this.

If you're in a hurry and just want to see the code 😀, here's the stackblitz link.

Prerequisites

Besides TypeScript, I assume you are familiar with styled-components. It is just another way of styling React components in a declarative way. In case you are not familiar, I recommend you to first check the basics in the docs before continuing with this tutorial.

I also assume you already know React and hooks. If you are not familiar with TypeScript, don't worry, you can still follow this tutorial with your JavaScript knowledge.

Why create your own modal

There are already many libraries out there that can be use to create a responsive, accessible modal in React. However, sometimes, you have requirements in your design that cannot be fully met by those libraries. Sometimes customizing the library to fit your need is difficult.

In such a case, you might want to create your own modal, but still follow the standards that are already in place.

My suggestion is that if a library can meet your needs, then just use that library; otherwise, create your own modal. The reason is that making your modal fully accessible is difficult. You may not want to go through all the hurdles.

React-modal is a popular library you can start with.

Creating the modal component

import React, { FunctionComponent, useEffect } from 'react';
import ReactDOM from 'react-dom';

import {
  Wrapper,
  Header,
  StyledModal,
  HeaderText,
  CloseButton,
  Content,
  Backdrop,
} from './modal.style';

export interface ModalProps {
  isShown: boolean;
  hide: () => void;
  modalContent: JSX.Element;
  headerText: string;
}

export const Modal: FunctionComponent<ModalProps> = ({
  isShown,
  hide,
  modalContent,
  headerText,
}) => {
  const modal = (
    <React.Fragment>
      <Backdrop />
      <Wrapper>
        <StyledModal>
          <Header>
            <HeaderText>{headerText}</HeaderText>
            <CloseButton onClick={hide}>X</CloseButton>
          </Header>
          <Content>{modalContent}</Content>
        </StyledModal>
      </Wrapper>
    </React.Fragment>
  );

  return isShown ? ReactDOM.createPortal(modal, document.body) : null;
};

Here is the actual modal component. It is pretty much self-explanatory. We have a functional component that receives ModalProps described in the interface. Through the props, we could set the title and content of our modal dynamically. We can determine whether our modal is open and we can also close it programatically.

Our HTML markup is created with styled-components imported from the modal.style.tsx file. Here is how our styles look like:

import styled from 'styled-components';

export const Wrapper = styled.div`
  position: fixed;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  z-index: 700;
  width: inherit;
  outline: 0;
`;

export const Backdrop = styled.div`
  position: fixed;
  width: 100%;
  height: 100%;
  top: 0;
  left: 0;
  background: rgba(0, 0, 0, 0.3);
  z-index: 500;
`;

export const StyledModal = styled.div`
  z-index: 100;
  background: white;
  position: relative;
  margin: auto;
  border-radius: 8px;
`;

export const Header = styled.div`
  border-radius: 8px 8px 0 0;
  display: flex;
  justify-content: space-between;
  padding: 0.3rem;
`;

export const HeaderText = styled.div`
  color: #fff;
  align-self: center;
  color: lightgray;
`;

export const CloseButton = styled.button`
  font-size: 0.8rem;
  border: none;
  border-radius: 3px;
  margin-left: 0.5rem;
  background: none;
  :hover {
    cursor: pointer;
  }
`;

export const Content = styled.div`
  padding: 10px;
  max-height: 30rem;
  overflow-x: hidden;
  overflow-y: auto;
`;

The interesting part of our modal is in the return statement.

return isShown ? ReactDOM.createPortal(modal, document.body) : null;

What is createPortal and why do we need it?

createProtal

createPortal is part of the ReactDOM API that allows us to render a React component outside the parent component. We usually render the React app in the root div element, but by using portals, we can also render a component outside the root div.

<html>
  <body>
    <div id="app-root"></div>
    <div id="modal"></div>
  </body>
</html>

We need portals in our modal because we only want to include the modal in the DOM when it is rendered. Having the modal outside the parent container also helps us avoid conflicting z-index with other components.

createPortal accepts two arguments: the first is the component you want to render, and the second is the location in the DOM where you want to render the component.

In our example, we are rendering the modal at the end of the body of the html (document.body) if the modal is open. If not, then we hide it by returning null.

Using the modal

To use our modal, we are going to create a custom React hook that will manage the state of the modal. We can use the custom hook in any component where we want to render our modal.

import { useState } from 'react';

export const useModal = () => {
  const [isShown, setIsShown] = useState<boolean>(false);
  const toggle = () => setIsShown(!isShown);
  return {
    isShown,
    toggle,
  };
};

Inside our App component, we could render our modal like this.

import React, { Component, FunctionComponent, useState } from 'react';
import { render } from 'react-dom';
import { Modal } from './modal/modal';
import { useModal } from './useModal';

const App: FunctionComponent = () => {
  const { isShown, toggle } = useModal();

  const content = <React.Fragment>Hey, I'm a model.</React.Fragment>;

  return (
    <React.Fragment>
      <button onClick={toggle}>Open modal</button>
      <Modal isShown={isShown} hide={toggle} modalContent={content} />
    </React.Fragment>
  );
};

render(<App />, document.getElementById('root'));

We use the isShown state and toogle function from the custom hook to show and hide the modal. At the moment, we are only showing a simple statement in our modal, which isn't very helpful.

Let us try to create a more specific kind of modal, a confirmation modal. In your app you may need several types of modal, like a confirmation modal, a success or error modal, or even a modal with a form in it. To customize our modal depending on the type of modal we need, we can create a component and pass it as a content to our modal props.

Here is the content of our confirmation modal.

import React, { FunctionComponent } from 'react';
import { ConfirmationButtons, Message, YesButton, NoButton } from './confirmation-modal.style';

interface ConfirmationModalProps {
  onConfirm: () => void;
  onCancel: () => void;
  message: string;
}

export const ConfirmationModal: FunctionComponent<ConfirmationModalProps> = (props) => {
  return (
    <React.Fragment>
      <Message>{props.message}</Message>
      <ConfirmationButtons>
        <YesButton onClick={props.onConfirm}>Yes</YesButton>
        <NoButton onClick={props.onCancel}>No</NoButton>
      </ConfirmationButtons>
    </React.Fragment>
  );
};

And the styles

import styled from 'styled-components';

export const ConfirmationButtons = styled.div`
  display: flex;
  justify-content: center;
`;

export const Message = styled.div`
  font-size: 0.9rem;
  margin-bottom: 10px;
  text-align: center;
`;

export const YesButton = styled.button`
  width: 6rem;
  background-color: yellow;
  :hover {
    background-color: red;
  }
`;

export const NoButton = styled.button`
  width: 3rem;
  background-color: lightgrey;
  :hover {
    background-color: grey;
  }
`;

This is a just simple component asking for a confirmation to delete an element, and the props are the actions we execute when the user clicks yes or no, and the message to display.

Now we could pass this confirmation component to our modal in App component.

import React, { Component, FunctionComponent, useState } from 'react';
import { render } from 'react-dom';
import { Modal } from './modal/modal';
import { ConfirmationModal } from './confirmation-modal/confirmation-modal';
import { useModal } from './useModal';

const App: FunctionComponent = () => {
  const { isShown, toggle } = useModal();
  const onConfirm = () => toggle();
  const onCancel = () => toggle();

  return (
    <React.Fragment>
      <button onClick={toggle}>Open modal</button>
      <Modal
        isShown={isShown}
        hide={toggle}
        headerText="Confirmation"
        modalContent={
          <ConfirmationModal
            onConfirm={onConfirm}
            onCancel={onCancel}
            message="Are you sure you want to delete element?"
          />
        }
      />
    </React.Fragment>
  );
};

render(<App />, document.getElementById('root'));

This is the modal that we get.

Making the modal accessible

An accessible website is a website that can be used by as many people as possible regardless of their disability. "The Web must be accessible to provide equal access and equal opportunity to people with diverse abilities."

If you try to run the code we have so far, you will notice that it is not so pleasant to use (at least for me 😀). When you click outside the modal, it will still be open. We cannot also use Esc key to close modal. Let us try to fix those small details in this section.

WAI-ARIA gives us guidelines on how to make a modal (or dialog as it is also called) accessible.

the element that will be our modal container needs to have role of dialog
the modal container needs to have aria-modal set to true
the modal container needs to have either aria-labelledby or aria-label

- clicking outside the modal (or backdrop) will close the modal

keyboard interaction where:

Esc key closes the modal
pressing Shift moves the focus to the next tabbable element inside the modal
pressing Shift + Tab moves the focus to the previous tabbable element
- when open, interaction outside the modal should not be possible, such as scrolling
- focus should be trapped inside the modal

Let us see how we can implement them in our modal.

HTML attributes for accessible modal

export const Modal: FunctionComponent<ModalProps> = ({ isShown, hide, modalContent }) => {
  const modal = (
    <React.Fragment>
      <Backdrop onClick={hide} />
      <Wrapper aria-modal aria-labelledby={headerText} tabIndex={-1} role="dialog">
        <StyledModal>
          <Header>
            <HeaderText>{headerText}</HeaderText>
            <CloseButton type="button" data-dismiss="modal" aria-label="Close" onClick={hide}>
              X
            </CloseButton>
          </Header>
          <Content>{modalContent}</Content>
        </StyledModal>
      </Wrapper>
    </React.Fragment>
  );

  return isShown ? ReactDOM.createPortal(modal, document.body) : null;
};

I have highlighted the changes that we have added to our modal. First, for the backdrop, we have added an onClick event so that when it is clicked, the modal will be close.

Next, we have added the attributes aria-modal, aria-labelledby, tabIndex, and role to the wrapper or container of our modal, just as specified by WAI-ARIA

The tabIndex attribute allows us to set the order of elements to be focused when pressing the tab key. We set it to -1 because we don't want the modal itself to be focused. Instead, we want the elements inside the modal to be focused when traversing the elements.

So, in our checklist above, we have accomplished the following:

the element that will be our modal container needs to have role of dialog
the modal container needs to have aria-modal set to true
the modal container needs to have either aria-labelledby or aria-label
clicking outside the modal (or backdrop) will close the modal

Now let us see how to add keyboard interaction with our modal.

Adding keyboard interaction

To allow user to close the modal when pressing ESC key, we need to add an event key listener to our modal. When ESC key is pressed and the modal is shown, our function to hide the modal will be executed. We are going to use useEffect hook to achieve this.

const onKeyDown = (event: KeyboardEvent) => {
  if (event.keyCode === 27 && isShown) {
    hide();
  }
};

useEffect(() => {
  document.addEventListener('keydown', onKeyDown, false);
  return () => {
    document.removeEventListener('keydown', onKeyDown, false);
  };
}, [isShown]);

Notice that we are removing the event listener in the return function of the useEffect hook in order to avoid memory leaks. The return function is executed when the component (modal) unmounts.

keyboard interaction where:

Esc key closes the modal
pressing Shift moves the focus to the next tabbable element inside the modal
pressing Shift + Tab moves the focus to the previous tabbable element

So, this is also checked. By the way, the Shift and Shift + Tab functionality is also already working, we can also tick it off.

Disable scrolling

One of our ARIA requirements is to not allow the user to interact with elements outside the modal, such as scrolling.

To disable scrolling, we are also going to add some code to our useEffect hook.

useEffect(() => {
  isShown ? (document.body.style.overflow = 'hidden') : (document.body.style.overflow = 'unset');
  document.addEventListener('keydown', onKeyDown, false);
  return () => {
    document.removeEventListener('keydown', onKeyDown, false);
  };
}, [isShown]);

When the modal isShown, we set the overflow style property of the body of the page to hidden to hide the scrollbar. To test this, we are going to later add some dummy text to our App component until it overflows, and see if hiding the scroll works when the modal is shown.

when open, interaction outside the modal should not be possible, such as scrolling

Focus trap

The last item in our checklist is to trap the focus inside the modal. We can traverse our elements inside the modal by clicking Shift or Shift + Tab. When we reach the last tabbable element, if we press Shift, the focus will move to an element outside the modal.

But that is not what we want. What we want is when we reach the last tabbable element and we keep traversing with the Shift key, the focus will go to the first tabbable element. It like a loop. Once we reach the end of the loop, we start from the beginning.

We can try to implement this functionality by getting all the focusable elements in our modal, and then loop through them to trap the focus, but since someone has already done this functionality before, we are just going to use an npm package called react-focus-lock.

npm i react-focus-lock

After installing the package, we can wrap our modal component with <FocusLock> component provided by the library.

import FocusLock from 'react-focus-lock';

// other codes and import above

export const Modal: FunctionComponent<ModalProps> = ({ isShown, hide, modalContent }) => {
  // other codes above

  const modal = (
    <React.Fragment>
      <Backdrop onClick={hide} />
      <FocusLock>
        <Wrapper aria-modal aria-labelledby={headerText} tabIndex={-1} role="dialog">
          <StyledModal>
            <Header>
              <HeaderText>{headerText}</HeaderText>
              <CloseButton type="button" data-dismiss="modal" aria-label="Close" onClick={hide}>
                X
              </CloseButton>
            </Header>
            <Content>{modalContent}</Content>
          </StyledModal>
        </Wrapper>
      </FocusLock>
    </React.Fragment>
  );

  return isShown ? ReactDOM.createPortal(modal, document.body) : null;
};

Now when the modal is open, our focus after pressing Shift will only be inside the modal.

Tick.

focus should be trapped inside the modal

Wow! Now we have a fully functioning modal with accessible features. Congrats 😀 🙌.

Conclusion

You can test all the functionalities we have implemented in this stackblitz link. I have added dummy text to the App component so that the content overflows and you can test if the scroll is disabled when the modal is shown. Don't be afraid to play around with it and customize it according to your want.

If you have liked this post or it has helped you, kindly please share it 😀

Asynchronous JavaScript: Callbacks, Promises, Async/Await

Naina Razafindrabiby — Mon, 15 Jun 2020 00:00:00 +0000

JavaScript is synchronous by design. When you execute a function, it has wait for it to finish before executing the next function. This can be a problem if the function executing takes a very long time to finish. It will block your application and make it unresponsive.

To avoid this, JavaScript provides us a way to execute functions asynchronously. By executing functions asynchronously, we can execute multiple functions at the same time without having to wait for each other. If you want learn more how JavaScript handles asynchronous programming, I recommend you to read my other post on how JavaScript works behind the scenes.

In this post, I want to show you how to handle asynchronous functions using callbacks, promises, and async/await.

Callbacks

A callback is a function that is passed as an argument to another function. It can either be synchronous or asynchronous.

When a callback is synchronous, it is executed immediately.

function readFile(filename, callback) {
  console.log('start');
  callback(filename);
  console.log('end');
}

readFile('test.js', (filename) => {
  console.log(filename);
});

If you run the code, you will see that the console logs appear in order.

start
test.js
end

When a callback is asynchronous, it will be executed at a later time after some other tasks have completed. The browser API have functions that execute callbacks asynchronously, such as setTimeout(), setInterval(), and functions for manipulating the DOM.

Let us convert our function above to execute the callback asynchronously.

function readFile(filename, callback) {
  console.log('start');
  setTimeout(() => {
    callback(filename);
  }, 1000);
  console.log('end');
}

readFile('test.js', (filename) => {
  console.log(filename);
});

If you run the code, you will notice that the console logs are no longer shown sequentially.

start
end
test.js

The callback is executed after one second, but the JavaScript engine didn't wait for it to finish before running the other functions.

Callback hell

Asynchronous functions usually use a callback to pass data that have been processed by the asynchronous function. The problem with callbacks is that when you have a lot of them nested to each other, the code becomes difficult to read and understand.

Look at this code. Can you tell what is happening?

function getEmployee(employeeName, callback) {
  console.log('getting employee data from database ...');
  setTimeout(() => {
    // mock data from database
    const employee = { username: employeeName, name: employeeName };
    callback(employee);
  }, 1000);
}

function getUser(username, callback) {
  console.log('getting user data from database ...');
  setTimeout(() => {
    // mock data from database
    const user = { username, role: 'Admin' };
    callback(user);
  }, 2000);
}

function getPermissions(role, callback) {
  console.log('getting user roles...');
  setTimeout(() => {
    // mock data from database
    const permissions = { role: role, permission: ['edit', 'view', 'delete'] };
    callback(permissions);
  }, 3000);
}

getEmployee('Peter', (employee) => {
  getUser(employee.username, (user) => {
    getPermissions(user.role, (permissions) => {
      console.log('permission:', permissions);
    });
  });
});

First, we are getting data about an employee from the database. We are simulating a call to the database with setTimeout() and returning a mock data. After receiving the employee data, we use the employee's username to get the associated user. Then after getting the associated user, we use the user's role to get the user's permissions. Finally we log the permissions.

We have introduced levels of nesting with our callback. The more the code is indented towards the right, the harder it becomes to read, follow and maintain. This will lead to more error-prone code. As the level of nesting deepens, we create a callback hell.

Promises

ECMAScript 2015 (aka ES6) introduced promises. A promise is a JavaScript object that represents the result of an asynchronous operation. It can be in one of three states.

pending. the initial state of the promise
resolved. represents a successful operation
rejected. represents a failed operation

As you will see, promises are a better way of dealing with asynchronous code.

Creating promises

To create a promise, you simply create an instance of the Promise class.

const promise1 = new Promise();

The promise constructor accepts a callback which is called the executor. It contains the code that will produce a result, and it is executed immediately (synchronous). The executor receives two arguments, resolve and reject functions. If the operation in the executor is successful, we pass the value to the resolve(). On the other hand, if it has failed, we pass the value to the reject().

const promise = new Promise((resolve, reject) => {
  // some code to do something
  const success = true; // my operation has succeeded

  if (success) {
    resolve('success');
  } else {
    reject('it has failed');
  }
});

A promise begins with the initial state. When the operation succeeds, it transitions into a resolve state, and if it fails, it goes into rejected state. Note once it has changed states, it is final. In other words, if it has resolved, it cannot reject, and vice-versa.

Consuming promises

There are three methods that we can use to consume the value of a promise — the then(), catch(), and finally().

then

The then() is the most important of the three. It is used to access the resolve and reject value of the promise. It accepts two callbacks.

The first callback is called when the promise has resolved, and its argument is the resolved value of the promise.The second callback is called when the promise has rejected, and its argument is the error.

const promise = new Promise((resolve, reject) => {
  // some code to do something
  const success = true; // my operation has succeeded

  if (success) {
    resolve('success');
  } else {
    reject('it has failed');
  }
});

function resolveCallback(value) {
  console.log('promise has resolved ', value);
}

function rejectCallback(value) {
  console.log('promise has rejected ', value);
}

promise.then(resolveCallback, rejectCallback);

catch

As the the name implies, the catch() is used to catch error in the promise. It accepts a callback function in which the argument is the error. When you use the catch method, you can omit the second argument of the then() , and handle the error gracefully inside the catch.

const promise = new Promise((resolve, reject) => {
  throw new Error('sorry something bad happend');
});

function resolveCallback(value) {
  console.log('promise has resolved ', value);
}

promise.then(resolveCallback).catch((error) => console.log('my error', error));

finally

The finally() method is always run whether the promise is resolved or rejected. It is good for performing clean up functions, and it avoids duplicating code in promise's then() and catch().

const promise = new Promise((resolve, reject) => {
  // some code to do something
  const success = true; // my operation has succeeded

  if (success) {
    resolve('success');
  } else {
    reject('it has failed');
  }
});

function resolveCallback(value) {
  console.log('promise has resolved ', value);
}

function rejectCallback(value) {
  console.log('promise has rejected ', value);
}

promise
  .then(resolveCallback)
  .catch((error) => console.log('my error', error))
  .finally(() => console.log('i am always executed'));

Chaining then()

The best thing about promises is that they are chainable. Remember the callback hell above? We can actually improve our code by converting the callbacks into promises.

function getEmployee(employeeName) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log('getting employee data from database ...');

      // mock data from database
      const employee = { username: employeeName, name: employeeName };
      resolve(employee);
    }, 1000);
  });
}

function getUser(username) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log('getting user data from database ...');

      // mock data from database
      const user = { username, role: 'Admin' };
      resolve(user);
    }, 2000);
  });
}

function getPermissions(role) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log('getting user roles...');

      // mock data from database
      const permissions = { role: role, permission: ['edit', 'view', 'delete'] };
      resolve(permissions);
    }, 3000);
  });
}

getEmployee('Peter')
  .then((employee) => getUser(employee.username))
  .then((user) => getPermissions(user.role))
  .then((permissions) => console.log('permissions', permissions));

So we have converted our functions into promises by returning a promise object. We have removed the callback in each of the functions. The asynchronous code runs inside the executor, and once it has finished, we execute the resolve() and pass our result.

The way we call our functions is very interesting. First, we call getEmployee(), and it returns a promise. As we said, we can consume the promise with the then() method. Inside the first then(), we return getUser(), which is also a promise. This means we can call another then() to consume the promise. The pattern continues until we reach a function where we do not return a promise. In our final statement, we console log final value.

This is much cleaner and more readable than when using callbacks. The code doesn't indent towards the right, but instead goes downwards, thus making it easier to follow.

Async/await

The async/await is a new feature introduced in ECMAScript 2017 (aka ES8) that makes it even easier to work with promises. Async/await is just basically a syntactic sugar around promises.

When you use async/await, you are writing asynchronous function in a synchronous way. No callbacks or whatsoever. You just write one statement after the other.

Let us convert our employee example to use async/await.

function getEmployee(employeeName) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log('getting employee data from database ...');

      // mock data from database
      const employee = { username: employeeName, name: employeeName };
      resolve(employee);
    }, 1000);
  });
}

function getUser(username) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log('getting user data from database ...');

      // mock data from database
      const user = { username, role: 'Admin' };
      resolve(user);
    }, 2000);
  });
}

function getPermissions(role) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log('getting user roles...');

      // mock data from database
      const permissions = { role: role, permission: ['edit', 'view', 'delete'] };
      resolve(permissions);
    }, 3000);
  });
}

async function getUserPermissions() {
  const employee = await getEmployee('Peter');
  const user = await getUser(employee.username);
  const permissions = await getPermissions(user.role);

  console.log('user permissions', permissions);
}

getUserPermissions();

In our example, our functions still return promises. I have added another function called getUserPermissions().

Notice that it is marked with async keyword. Inside this method, we call our functions that return promises like any other function, but we mark them with await keyword. This basically tells the compiler, 'Wait for me before moving to the next statement'. So instead of using then() to access values returned by the promise, we just await the function and store the return value in a variable.

Isn't this easier to read than chaining then()'s in promises? You await on functions that return promises.

The thing to note is that you can only use the await keyword inside a function that is marked with async and functions marked with async will always return a promise (even if you don't await any function). That means you can always use then() on an async function.

async function getUserPermissions() {
  const employee = await getEmployee('Peter');
  const user = await getUser(employee.username);
  const permissions = await getPermissions(user.role);

  console.log('user permissions', permissions);
}

getUserPermissions().then(() => console.log('success'));

To handle errors when using async/await, you can wrap the function in a try/catch block.

async function getUserPermissions() {
  try {
    const employee = await getEmployee('Peter');
    const user = await getUser(employee.username);
    const permissions = await getPermissions(user.role);
  } catch {}

  console.log('user permissions', permissions);
}

Conclusion

Congratulations for reaching up to this point!

Before 2015 we used callbacks to access values returned by asynchronous functions, but as we have seen, when we nest too many callbacks, our code becomes difficult to read and maintain.

Promises came to the rescue. We can wrap asynchronous functions in a promise, and we are able to access values by using then(). We can chain our then()'s beautifully to make the code more readable and maintainable. Then in 2017 (pun intended), async/await made it even easier to work with promises and asynchronous code. We can write with promises in a synchronous fashion.

If you have liked this post or it has helped you, kindly please share it 😀

Lesser Known Use of React Key Props

Naina Razafindrabiby — Mon, 08 Jun 2020 00:00:00 +0000

Most of us have first encountered the React key prop when displaying a list of elements. If we forget to add the key prop to each element in the list, the browser console throws us a warning.

Warning: Each child in a list should have a "unique" key prop.

The key props is used by React to determine which of the components in the collection needs to be re-rendered instead of re-rendering the whole collection. After adding a key to each element, the warning disappears.

But the key prop can be used on just any React component (not only in lists). When we change the key on a component, the current instance of the component is discarded and replaced with a new one.

Let us see with this simple example.

import React, { useState, useEffect } from 'react';
import { render } from 'react-dom';

const FruitSmoothie = ({ name }) => {
  const ratings = ['bad 😞', 'good 😊', 'very good 😎'];
  const [rating, setRating] = useState(ratings[1]);

  const onChangeRating = (event) => {
    setRating(event.target.value);
  };

  useEffect(() => {
    console.log('mounted');
    return () => {
      console.log('unmounted');
    };
  }, []);

  return (
    <div>
      <div style={{ display: 'inline-block' }}>You are making a/an {name} smoothie 🥤.</div>
      <select onChange={onChangeRating}>
        {ratings.map((r) => (
          <option key={r} value={r}>
            {r}
          </option>
        ))}
      </select>
    </div>
  );
};

const App = () => {
  const fruits = ['avocado 🥑', 'strawberry 🍓', 'banana 🍌', 'pear 🍐'];

  const [selectedFruit, setSelectedFruit] = useState(fruits[0]);

  const onSelectFruit = (event) => {
    setSelectedFruit(event.target.value);
  };

  return (
    <>
      <select onChange={onSelectFruit}>
        {fruits.map((f) => (
          <option key={f} value={f}>
            {f}
          </option>
        ))}
      </select>

      <FruitSmoothie key={selectedFruit} name={selectedFruit} />
    </>
  );
};

render(<App />, document.getElementById('root'));

The code above allows you to select a fruit. After picking a fruit, a statement about a smoothie from your selected fruit will show. You can also give a rating.

Notice that in the <FruitSmoothie /> component, I have added a console.log in the useEffect hook to show when the component mounts and unmounts.

I have also put a key prop in the <FruitSmoothie /> component. When you select a fruit from the dropdown, the selectedFruit state is updated and the key for the <FruitSmoothie /> changes.

We see in the console logs that the component is unmounted, then mounted again. This means that whenever the key changes, a new instance of the component is being created.

unmounted
mounted

The state of the component is also reset. If you give a rating of very good, then change the fruit, the rating will be set back to the default rating (which is the good rating).

The lesson from this post is that we can use the key prop to force a re-render on a component and to reset its state.

A practical example of its usage is when working with a form.

In your form, you control its state, validation, and the status of each input. For each input, you track whether it has been touched or changed.

Now in order to reset the form, you can create a function that will set the state of the form and all the components in it back to their original value. It might involve some complex logic to implement.

But another simple way is to just change the key prop in the form. All the components inside the form will be reset and will give you a new fresh form.

More resources

Recommendation fully uncontrolled component with a key

Understanding react key prop

Learn Something New by Reading the Documentation (docs)

Naina Razafindrabiby — Sun, 24 May 2020 00:00:00 +0000

For most of us, the documentation is the last resource we want to consult when trying to learn something new. We usually think it is just a big wall of boring descriptive text that we don't all need. Instead, we go out in search of a shorter and livelier version of it in video tutorials and blog posts.

But can we always avoid the docs? I don't think so.

If you are a content creator of a course, reading the docs is a must. How can we have the video tutorials we all like if no one reads the docs? The content of our tutorials comes from the docs.

It the single source of truth. Other tutorials or materials might contain outdated, misleading or wrong information, but the official documentation will rarely do so. If there is something new in the language/framework API, you can immediately read the docs to know how to use it. You don't have to wait for someone else's blog post or tutorial.

In this post, let us see how we can go about reading developer docs for learning. Not all docs are bad. There are many that are pleasing and enjoyable to read and follow.

Navigating the documentation

A good documentation is divided up into several sections, and each section serves a different purpose. This helps the reader find the information they need quickly.

Let us say you want to learn React. Where do you start?

Getting started

You should start here. This section contains the necessary setup to use the framework. What software and libraries do you need to pre-install? How do you install the framework?

Everything you need to prepare your environment is described in this section. Sometimes it also contains the simplest example of using the framework.

Tutorials

This contains a step-by-step explanation on how to use the basic features of the framework. If you are a beginner, you should follow the tutorial because it will give you a hands-on feel of the framework.

In the official React tutorial, you build an interactive tic-tac-toe game.

Guides

The guides contain information on how to achieve a specific thing with the framework. How do you create a component? State? Higher-order components? These are in the the main concept and advance guide of the React docs.

The guide provides many code samples. You can use the guides as a reference on how to do things.

API reference

The API reference contains all the information needed to work with the API. It describes all the classes and functions that are available to use in the framework. It contains a description of what they do, the arguments, and return types.

You should check the API reference to gain a deeper knowledge of the capabilities of the framework.

In case you forget the syntax or arguments of a function, you can quickly check the API reference.

Most of the documentations out there contains the sections I mentioned or similar, so you should be able to know where to check information.

You don't have to read the documentation in the order that I listed above. How you go about it all depends on the information you need and your level.

Understanding function parameters

If you have visited the MDN web docs, I'm sure have seen something like this.

let new_array = arr.map(function callback( currentValue[, index[, array]]) {
    // return element for new_array
}[, thisArg])

This is the syntax for the Array.map() function. Many have been confused what the square brackets mean, including me, but it simply means that a parameter is optional.

Let us try to break down the arguments of the function.

The first argument is a callback function. The callback function can receive up to 4 arguments. The first argument is the currentValue in the array, and it is required.

After the currentValue , we see index preceded by a square bracket with a comma [, index . This indicates that index is an optional argument. We see the same thing with [, array, which also means that array is an optional argument. Then we close the square brackets ]].

The second argument of the map() function is a this value that will be used when executing the callback. As you might have already guessed, it is also optional.

Many docs today no longer use this syntax because it is confusing to readers. Instead, they just indicate in text whether the argument is required or optional.

What to do if you don't understand the documentation

Sometimes the documentation is just bad. Or it can be good, but you are still confused and not sure.

What I usually first do is to look for other examples outside the documentation. I will google the topic and look for more explanations in blog posts, and stackoverflow answers.

If I still couldn't find what I'm looking for, I will ask in online community groups --- Stackoverflow, Twitter, Spectrum Chat, Discord.

You can also consult YouTube for video resources, or look for code in GitHub that uses the technology you are learning.

Conclusion

We should not be afraid of reading the docs. It is the primary source of information. We can use it to learn new things and keep ourselves updated.

By learning how to navigate around documentation, we can quickly find the information we need.

Do you read the docs for learning, or you use other resources? Please share your experience.

JavaScript Behind the Scenes: The Event Loop

Naina Razafindrabiby — Sun, 17 May 2020 00:00:00 +0000

Have you heard of the event loop in JavaScript? Do you know how it works? If you want to become a better JavaScript developer, you need to know how JavaScript works behind the scenes.

In this post I want to give you a visual explanation and understanding of how JavaScript executes your functions, and how the event loop works.

Single-threaded model of JavaScript

JavaScript is a single-threaded and synchronous programming language. What is that mean?

When we say single-threaded, it simply means that JavaScript can only perform one operation at a time. It goes through the lines of code one by one. Until the previous code has finished execution, it will not proceed to execute the next code (synchronous execution).

But there is a problem with this model. If there is a long operation that is taking place, it could block the whole thread because the next operation has to wait until the long operation is done. This would make the web page unresponsive.

Take for example the following code.

function download(message) {
  console.log(message);
  // emulate time consuming task
  for (let i = 0; i < 10000000000; i++) {}
  console.log('download complete');
}

console.log('Start script...');
download('downloading file started');
console.log('Done!');

If you run this code in your browser console, you will see the following output.

Start script...
downloading file started
download complete
Done!

Depending on how fast your computer is, you will notice that the second message stays there for some period of time. This is because the thread is being blocked by the long executing task, and it cannot proceed to execute the next function until the previous function is finished.

How does JavaScript execute our code above?

Call stack

The JavaScript engine has a call stack. The call stack keeps track of the function that is currently being called and the functions called inside a function. The JavaScript engine uses the call stack to know which function to execute next.

It works in a Last-In-First-Out fashion (LIFO). The last function that is added into the call stack is the first one that is run.

Think of the stack as a pile of books. The last book that you have added on to the pile is the first book that you will pick out of the pile.

Let us see what is happening in the call stack from the example above.

The first function added into the stack is the console.log('Start script ...').
When it finishes, it gets popped out of the stack and the next function, download(), is pushed into the stack.
Inside download, we have another console.log, so it gets pushed into the stack and it executes. After it finishes, it gets popped out.
Then the for loop is executed.
Then we see the last console.log inside download() pushed into the stack.
After executing, it is popped out of the stack.
Because donwload has finished executing, it is also popped out of the stack.
Finally the last console.log is added on the stack and executed.

Asynchronous JavaScript

To prevent blocking the thread for long operations, the web API provides us with functions that allow us to run code asynchronously. As opposed to synchronous functions, asynchronous functions don't wait for one function to finish before executing the next function.

You can write asynchronous functions using asynchronous callbacks. Async callbacks are just functions that are passed as arguments to another function, but will be called at a later time. An async callback function basically tells the browser, "Hey do this thing, but don't wait for me to finish. I'll call you back when I am done".

When you wrap long executing functions inside an asynchronous callback, they become non-blocking functions because the browser will be able to do other things instead of waiting for the function to finish.

A real life analogy is when you cook food. You can do other activities while the food is being cooked. You just have to keep checking on it if it is done or not.

Let us convert our example above to be asynchronous.

function download(message) {
  console.log(message);
  // emulate time consuming task
  for (let i = 0; i < 10000000000; i++) {}
  console.log('download complete');
}

console.log('Start script...');
setTimeout(() => download('downloading file...'), 1000);
console.log('Done!');

Again, if you run the code, you will see the following output.

    Start script...
    Done!
    downloading file...
    download complete

Notice that this time the last console.log(Done!) comes before the console logs inside the download function.

Why is that?

The JavaScript engine didn't wait for the download() to finish before executing the next statement because we wrapped download() inside an asynchronous callback function.

The setTimeout() function is part of the API of the browser (web API), and it executes the callback function after x milliseconds as specified. The web API contains other functions that allow us execute functions asynchronously. For example, functions that allow us to interact with the DOM, setInterval, and HttpRequests functions.

It is important to note that callback functions can either be synchronous or asynchronous. A callback function is asynchronous when we wrap it with the functions provided by the web API, such as in the example above. It will be executed at a later time.

Here is an example that uses synchronous callback.

const books = [
  { title: 'fiction', author: 'Arthur' },
  { title: 'stories', author: 'Connor' },
  { title: 'non fiction', author: 'James' },
];

console.log('first');
const titles = books.map((b) => {
  console.log('book', b.title);
  return b.title;
});

console.log('end');

When you run the code, you will see that the code is executed in order.

    first
    fiction
    stories
    non fiction
    end

Event loop

How does JavaScript execute asynchronous functions behind the scenes?

Let us look at this example again.

function download(message) {
  console.log(message);
  // emulate time consuming task
  for (let i = 0; i < 10000000000; i++) {}
  console.log('download complete');
}

console.log('Start script...');
setTimeout(() => download('downloading file...'), 1000);
console.log('Done!');

Here, the first console.log(start script...) is pushed into the call stack, executed, then popped out of the stack. We already know that.

Then the setTimeout() is pushed into the call stack. Something interesting happens at this stage. After it is placed into the stack, the web API starts a timer that will expire after 1000milliseconds (that is what we specified in the setTimeout function).

Because setTimeout() has executed, it is removed from the call stack and the next function, console.log('Done!), is pushed into the stack and executed.

Notice that the long operation download() which is wrapped by the the setTimeout() function has not run yet. That is why you see console.log('Done!') before the console logs inside download(). The setTimeout() just starts a 1000ms timer.

After 1000ms has expired, the download() function is put into the callback queue. The callback queue contains the functions that will soon be executed.

Now here is where the event loop comes in. The event loop is a continuous running process that constantly checks if the call stack is empty or not. If the call stack is empty, it will move the function from the callback queue into the call stack and it gets executed.

In our example, after the console.log('Done!') has executed, the call stack becomes empty. The event loop checks the call back queue to see if there is anything to execute. It sees thedownload, so it pushes it to the call stack to be executed.

It's that simple.

Once the download() is on the call stack, it will execute the function. At this point you already know how the call stack is going to look like.

Conclusion

JavaScript uses a single-threaded, synchronous model. As we have seen, this poses a challenge when a long process blocks the thread. Through the help the web API and event loop, we are able to call functions asynchronously without blocking the thread.

If you are executing JavaScript in the server, Node.js also provides an API that allows you to call functions asynchronously.

I hope this post has given you a better undestanding of how JavaScript works.

Video resource

What the heck is the event loop anyway

Understanding How Array.reduce works in JavaScript

Naina Razafindrabiby — Sun, 10 May 2020 00:00:00 +0000

JavaScript has a lot of functions to manipulate and transform elements in an array. One of those is the Array.reduce function. As its name implies, it is used to reduce an array of values to a single value. It is really powerful, yet many JavaScript developers don't know how to use it nor how to take advantage of its power.

In this post, I want to give you a better understanding of how reduce works, and what you could do with it.

Syntax

Let us start with the syntax.

arr.reduce(callback, initialValue);

The first argument of reduce is a callback function that is executed on each iteration of the elements in the array. In case you are not familiar with callbacks, here is an article about callbacks.

On each iteration, the callback returns a value, and that value is going to be used in the next iteration. This value is stored in what we call accumulator, and after iterating through all the values in the array, the final value of the accumulator is returned.

The second argument is the initial value. It can be a number, a string, an array, or an object. It will be the initial value of the accumulator.

This will all be clearer when we do the example below.

Callback signature

The callback function receives up to four arguments. It has a function signature like this.

function reduceCallback(accumulator, currentValue, index, srcArray) {
  // code to do some manipulation
  return accumulator;
}

Most of the time you will only use the first three arguments.

accumulator. It contains the return value of the last callback. If we are at the first element, its value is going to be the initialValue. Its final value will be the return value of the reduce function.
currentValue. This is the current element in the array during the iteration.
index. The position of the element in the array.
srcArray. This is the array we are iterating upon.

In the callback function, it is important that you return always return the accumulator , otherwise your function will not work as intended.

It is also important to always specify an initial value. If initial value is not specified, the reducer will take the first item in the array as an initial value, and it might not also work as you desire.

How it works

Let us suppose we want to add the sum of numbers inside an array. Using a for ... of loop we can do it like this.

// initialization
let sum = 0;

// array of values
const numbers = [1, 2, 3, 4, 5];

for (const num of numbers) {
  sum += num;
}

console.log('sum:', sum); // outputs 15

We have declared and initialized a sum variable to 0. We also have an array of numbers. For each number in the array, we add the number to the sum, then console.log the sum. I think this is simple enough.

To achieve the same output using reduce, we could do the following.

const numbers = [1, 2, 3, 4, 5];
const add = function (acc, curr) {
  return acc + curr;
};
const sum = numbers.reduce(add, 0);
console.log('sum:', sum); // outputs 15

As I have explained above, the reduce function takes a callback function as its first argument. Our callback function here is the add function, and we are passing it as the first argument to the reduce function.

Here we are also initializing our sum value to 0. Notice that 0 in the reduce function?

If we try to console log the values of the acc and curr, we would be able to understand it better.

const numbers = [1, 2, 3, 4, 5];
const add = function (acc, curr) {
  console.log(`accumulator: ${acc}, current: ${curr}`);
  return acc + curr;
};
const sum = numbers.reduce(add, 0);
console.log('sum:', sum); // outputs 15

Output.

We see 5 console logs for add because we have 5 elements in our array. The first value of our accumulator is 0, because we passed 0 as the initialValue of the reducer. On each iteration, our current value is added to the accumulator. The final call of the callback returns to us an accumulator value of 10, and current value of 5. When we add 10 + 5, we get 15, which is the final value of our accumulator. And that is the final value that is returned by reduce.

Our code above can be shortened by using anonymous function and implicit return.

const numbers = [1, 2, 3, 4, 5];
const sum = numbers.reduce((acc, curr) => acc + curr, 0);

Interesting use cases of reduce

What makes reduce powerful is that the type of the accumulator value doesn't have to be the same as the type of the initial value of the reducer. That means you can transform an array to an object, a number, string, or another array.

Creating a tally of items

You want to know the total for each item in the array. In this example, we are transforming an array of strings into an object.

const food = ['pasta', 'rice', 'brocolli', 'pasta', 'cereal', 'chicken', 'rice', 'brocolli'];

const basket = food.reduce((acc, curr) => {
  if (!acc[curr]) {
    acc[curr] = 1;
  } else {
    acc[curr] += 1;
  }

  return acc;
}, {});
console.log(basket); // { pasta: 2, rice: 2, brocolli: 2, cereal: 1, chicken: 1}

Flattening an array of arrays

You want to transform an array of arrays into a single array.

const numbers = [
  [1, 2],
  [3, 4],
  [5, 6],
  [7, 8],
  [9, 10],
];
const flattened = numbers.reduce((acc, curr) => acc.concat(curr), []);
console.log(flattened); // [1,2,3,4,5,6,7,8,9,10]

A new feature in ES10 allows you to achieve the same thing with Array.flat().

const flattened = numbers.flat();
console.log(flattened); // [1,2,3,4,5,6,7,8,9,10]

Calculating total

We already saw this example above. We want to perform an arithmetic operation on the items in the array.

const numbers = [2, 4, 6];
const product = numbers.reduce((acc, curr) => curr * acc, 1);
console.log(product); // 48

Pipelining functions

Piping refers to a series of function that transforms an initial value to a final value. The output of the previous function will be input of the next function. We can create our pipe function with reduce.

const square = (value) => value * value;
const double = (value) => value * 2;
const halve = (value) => value / 2;

const pipeline = [square, double, halve];

const result = pipeline.reduce(function (total, func) {
  return func(total);
}, 3);

console.log(result); // 9

So here we have a pipeline that squares a value, doubles it, and then halves it. We execute the pipeline with reduce.

If we reorder our pipeline, it will give us a different result.

const pipeline = [double, square, halve];

const result = pipeline.reduce(function (total, func) {
  return func(total);
}, 3);

console.log(result); // 18

Conclusion

That's it. At first it might seem intimidating to use, but with practice, it will become more intuitive to you. I hope this short post has reduced your fear of using reduce function 😉.