Forem: Franco D'Alessio

Yes, your users care about how you write code

Franco D'Alessio — Mon, 28 Sep 2020 13:09:55 +0000

This post was originally published in my personal site.

The experience of the user is the only thing that matters?

It's a common thought and a widespread idea that the only thing that matters is the user experience. If a certain product is well designed, the user will have a good experience and be able to accomplish his/her goal. And that's all that matters.

Following this line of thought, the user doesn't care about how the website was coded or what your technology choices were. She doesn't care if you have a great readme or comment your code. She doesn't care if you apply good design patterns or if you write good integration tests for your application. She doesn't even know (or want to know) all this stuff. If she has a great experience using your product, that's enough.

I totally agree that the user experience is what matters the most. We build great products to save people's time, money or improve their lives in some other way. But I think that we cannot speak about user experience without taking into consideration the way we write your code and our technology choices. These things have indirect, but huge implications in your user experiences.

Imagine this situation

You're a front-end developer working for a certain company. As every good team does, you're consistently trying to find out what your users struggle with when using your product, so you can improve it and provide a better experience.

Let's say that using Hotjar, you find out that your users are struggling with some filters. The way some of them are grouped is confusing, and the users are struggling to find the ones they need.

You're asked to fixed this and your PM asks you how much time you think you'll need.

And here comes the problem

If your application is well written, documented, uses solid design patterns, latest technologies that simplify your code, has good integration tests for that filters functionality, deployment is very simple, etc., it will most probably be an easy task. Let's say you can fix it in 2 days.

But, on the other hand, if your application code is a mess, uses old technology that only a one person of the team understands, has files with over a thousand lines, has no tests, the deployment process is horrible and often fails, etc., it will be a lot more complicated. You will struggle to make it work, and you most probably will introduce new bugs.

In this scenario, 2 days will not be enough, and you will probably need a week or more to finish this task.

So, does the user care about how your code is written?

Indirectly, yes, of course! She's struggling with your product's filters. She expects to find the filters she needs easily, but she doesn't. And she doesn't accomplish her goal of finding what she needs.

She's having a bad experience, and she wants this to be fixed immediately. Maybe she even took the time to write and email and complain about this. And what will you answer? "Sorry, but this will take over a week because our code is horrible"?

If you and your team had done things correctly, this issue would be solved in two days, and would be a minor issue. But because your code is a mess, you need a lot more time and resources and you have the risk of losing a lot of users who are struggling with this same thing.

So does it matter if you use React or Vue?

No! Of course not. We should stop discussing these things that have little impact and ultimately are a matter of preference (and a waste of time). Both React and Vue (and other JS frameworks) are great and you can accomplish what you need with any of them. Using semicolons is the exact same thing as not using them. Using tabs over spaces doesn't produce any real impact.

Instead, we should focus on discussing things that have real impact. We should try to include latest technology that really makes our lives as developers easier and simplifies our code. We should use solid design patterns. We should document our code. We should write good integration tests for common user cases. We should have a simple and predictable deployment process that allows us to hit production with new features regularly.

These (and a lot more) are the things that matter and produce real impact. And ultimately, the things that indirectly matter to your users. Because if you do a good work, you will deliver what your users really need much faster. And that means providing a great experience, which is the most important thing.

My advice for you

If I may, my advice for you is that next time that you're discussing something technical or trying to choose a new technology for your project, think first about your users. Think about what's best for them. Think if this decision will really help you to give them what they need in an easier, faster way. Think if it will really make your life as a developer easier the next time users needs something fixed or a new feature.

Thanks for reading ❤️

Understanding React's Error Boundaries

Franco D'Alessio — Mon, 08 Jun 2020 12:13:55 +0000

This post was originally published in my personal site.

In the past, Javascript errors inside components used to corrupt React’s internal state and produce a corrupted UI in place. React did not provide any way to handle these errors gracefully, and could not recover from them.

An important change was introduced in React version 16. Now any uncaught Javascript error will result in unmounting the whole React component tree. This leaves no room for corrupted UIs.

Why was this change introduced? Well, the React team believes that it is a bad practice to leave a corrupted UI in place, because it may have dangerous outcomes. For example, in a bank app, it is worse to display a wrong account balance than to render nothing.

That sounds logical, but still a Javascript error in some part of the UI shouldn’t break the whole app. To solve this problem, the React team introduced a new concept called error boundary.

What is an error boundary?

Error boundaries are React components. Their role is to catch Javascript errors anywhere in their child component tree, log them and display an alternative UI instead of the component tree that crashed.

Error boundaries catch errors during:

Rendering
Lifecycle methods
Constructors

But it's important to know that error boundaries do not catch errors for:

Event handlers
Async code
Server side rendering (SSR)
Errors thrown in the error boundary itself

Error boundaries work like a Javascript catch {} block, but for components.

Before we create an error boundary component...

We need some app to test it. So let's create a very simple UI where we have two sections: News and Chat.

Both sections have a button that will simulate a Javascript error when clicked.

This is our News component:

import React from "react";

const styles = {
  newsBox: {
    border: "1px solid #333",
    margin: "0.5rem 0",
    height: "50px",
    width: "300px",
  },
};

const News = () => {
  const [error, setError] = React.useState(false);

  const handleClick = () => {
    setError(true);
  };

  if (error) throw new Error("News error!");

  return (
    <>
      <h2>News</h2>
      <div style={styles.newsBox} />
      <div style={styles.newsBox} />
      <button onClick={handleClick}>Throw Error</button>
    </>
  );
};

export default News;

The Chat component, very similar to the previous one:

import React from "react";

const Chat = () => {
  const styles = {
    chatBox: {
      border: "1px solid #333",
      margin: "0.5rem 0",
      height: "150px",
      width: "300px",
    },
  };

  const [error, setError] = React.useState(false);

  const handleClick = () => {
    setError(true);
  };

  if (error) throw new Error("News error!");

  return (
    <>
      <h2>Chat</h2>
      <div style={styles.chatBox} />
      <button onClick={handleClick}>Throw Error</button>
    </>
  );
};

export default Chat;

And our App component:

import React from "react";
import News from "./News";
import Chat from "./Chat";

export default function App() {
  return (
    <div style={{ padding: "0.5rem 1.5rem" }}>
      <h1>Welcome!</h1>
      <hr />
      <News />
      <hr />
      <Chat />
    </div>
  );
}

Our app looks like this:

Now let's see what happens when a Javascript error is thrown.

Without error boundaries

If we click one of the Throw Error buttons, we would expect the whole app to break. As we previously discussed, React 16 has this behavior for any uncaught Javascript error.

And effectively, it does break:

Now let's see how to catch these errors with an error boundary component.

How to create an error boundary component

Creating an error boundary component is very easy. The first thing you should know is that error boundaries have to be class components. Right now there is no way to create an error boundary using a functional component.

import React from 'react';

export default class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
  }

  render() {
    return...
  }
}

The next thing you should do is adding the componentDidCatch method. This method receives two parameters: the error and the errorInfo.

As we want to display a fallback UI in case of error, we need to have some state that indicates that. So let's add it, and update the state when an error is caught:

import React from 'react';

export default class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { error: null, errorInfo: null };
  }

  componentDidCatch(error, errorInfo) {
    this.setState({
      error: error,
      errorInfo: errorInfo,
    });

    // Log error info somewhere
  }

  render() {
    return ...
  }
}

You could also log the errorInfo somewhere.

Great! The last step is to complete the render function. We want to render a fallback UI if there is an error. Otherwise, we just need to render the children.

import React from "react";

export default class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { error: null, errorInfo: null };
  }

  componentDidCatch(error, errorInfo) {
    this.setState({
      error: error,
      errorInfo: errorInfo,
    });

    // Log error info somewhere
  }

  render() {
    if (this.state.errorInfo) {
      return <h2>Something went wrong!</h2>;
    }
    return this.props.children;
  }
}

Perfect! We have our error boundary component, now let's see how we can use it.

Catching errors with an error boundary component

Using our new error boundary component is very easy. We just need to include it in our component tree as a wrapper:

export default function App() {
  return (
    <ErrorBoundary>
      <div style={{ padding: "0.5rem 1.5rem" }}>
        <h1>Welcome!</h1>
        <hr />
        <News />
        <hr />
        <Chat />
      </div>
    </ErrorBoundary>
  );
}

This way, when a Javascript error is thrown, it will be caught by our error boundary and the fallback UI will be displayed instead:

Using multiple error boundaries

The previous example worked fine, we were able to catch our error and display a fallback UI.

However, our entire application was replaced by this error message, even though the error was thrown by only one of the components.

The good news is that you can have multiple error boundaries for different sections of your application.

For example, Facebook Messenger wraps content of the sidebar, the info panel, the conversation log, and the message input into separate error boundaries. If some component in one of these UI areas crashes, the rest of them remain interactive.

In our case, we could use an error boundary for our News component, and another one for our Chat component:

export default function App() {
  return (
    <div style={{ padding: "0.5rem 1.5rem" }}>
      <h1>Welcome!</h1>
      <hr />
      <ErrorBoundary>
        <News />
      </ErrorBoundary>
      <hr />
      <ErrorBoundary>
        <Chat />
      </ErrorBoundary>
    </div>
  );
}

Now, if our News section throws a Javascript error, our Chat section won't be affected:

And this is the real power of error boundaries. If you use multiple of them, you can isolate errors in different, independent sections, without affecting the whole application.

That's it!

I hope this post was helpful and now you understand better what error boundaries are and how to use them. Thanks for reading! ❤️

Writing an integration test with React Testing Library

Franco D'Alessio — Mon, 25 May 2020 12:49:07 +0000

This post was originally published in my personal site.

At this point I think I don't have to explain the importance of testing your applications. Automated tests allow you to catch bugs while still developing and avoid getting a call at 2am because your application is not working as expected.

It's all about confidence. When shipping new code, you want that confidence. You want to know that your application will work just fine. Of course you can't know, but if you have a bunch of great tests, you will be a lot more confident.

Yes, you need to invest time writing tests. But in the long run, it will save you a lot of time and will avoid you a lot of headaches.

But can you have too many tests?

Nobody argues that testing applications is a waste of time anymore. But we still have this problem of writing too many tests. It's a big challenge to understand what should be tested, and also how to test it in order to get as much confidence as possible.

A while back, Guillermo Rauch‏ tweeted this:

Guillermo Rauch

@rauchg

Write tests. Not too many. Mostly integration.

16:43 PM - 10 Dec 2016

185 513

Many times we hear that our tests should cover 100% of our code. And that's simply not always a good idea. There is always a point that is the turning point. Once you get that X% of coverage, the new tests you write are not really helping. The number is different for every project, but it's never as high as 100%.

When you go over that point, you start spending time testing things that really don't need to be tested. You test things that have no logic at all. You have one line of code that is uncovered and you write awful tests, usually involving implementation details, just to get that 100% coverage.

You may not see the issue right away, but as you start to have more and more tests like that, it becomes hard to mantain them and ultimately slow the whole team down. The important thing to have in mind here is that you should write tests to have more confidence that your application is working fine. And these kind of tests doesn't help to increase that confidence at all.

Ok, and why integration tests?

The three most common types of tests are: unit, integration and end to end.

Unit tests are faster to write and of course, cheaper. But they also don't give you a lot of confidence. It's fine testing if component A renders correctly, but if you don't also test it together with B and C, you won't have much confidence in your application.

End to end tests give you a lot of confidence, because you are testing everything. But they also take a lot of time to write, and are of course the most expensive option.

Integration tests are the perfect balance. You test how your components work together, but mock some things (for example, HTTP requests) so it doesn't take you a lot of time to write them. And they give you a lot of confidence as well. Once you start testing your components this way, you'll see that you may not need a lot of your unit tests at all.

This is why it's a great idea to spend most of your time writing integration tests.

This doesn't mean that you should only write this kind of tests.

This also doesn't mean that unit and end to end tests are useless.

It just means that it's intelligent to spend most of your time writing integration tests, because they provide you with a great balance on the trade-offs between confidence and effort.

A quick note on mocking

When you write integration tests, you want to mock as less as possible. Mocking stuff reduces the confidence in that test. So just keep that in mind.

Have you heard of React Testing Library?

React Testing Library is by far the best and most popular testing library available for React right now.

Its creator, Kent C. Dodds, wrote it with this in mind:

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

He's also a big advocate of integration tests, so let's use this library to write one!

First we need an application

I wrote a small app that consists of two pages. In the home page, you can write a postId. The Submit button is disabled until you write something.

Once you write a postId and press the Submit button, you navigate to a second page, /post/:postId.

When you land on this page, you will first see a Loading... message:

An HTTP request is fired to the JSON Placeholder API using the provided postId, and once the data is received, the post is displayed. This page also has a link to go back to the Home page.

Here is the full code:

import React from "react";
import { BrowserRouter as Router, Route, Link, Switch } from "react-router-dom";
import { fetchPost } from "./api";

export default function App2() {
  return (
    <Router>
      <Switch>
        <Route exact path="/" component={Home} />
        <Route exact path="/post/:postId" component={Post} />
      </Switch>
    </Router>
  );
}

function Home({ history }) {
  const [postId, setPostId] = React.useState("");
  return (
    <div>
      <h1>Welcome!</h1>
      <h2>Search for a post by its ID</h2>

      <label htmlFor="postId">Post ID: </label>
      <input
        id="postId"
        value={postId}
        onChange={e => setPostId(e.target.value)}
      />
      <button
        disabled={!postId}
        onClick={() => history.push(`/post/${postId}`)}
      >
        Submit
      </button>
    </div>
  );
}

function Post({ match }) {
  const { postId } = match.params;
  const [post, setPost] = React.useState();
  React.useEffect(() => {
    (async function fetch() {
      setPost(await fetchPost(postId));
    })();
  }, [postId]);
  return (
    <div>
      <h1>Post {postId}</h1>
      {!post ? (
        <p>Loading...</p>
      ) : (
        <>
          <h2>{post.title}</h2>
          <p>{post.body}</p>
        </>
      )}
      <Link to="/">Back to Home</Link>
    </div>
  );
}

And this is the api.js file:

export const fetchPost = async postId => {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/posts/${postId}`
  );
  return response.json();
};

You can play with the application in this code sandbox.

Now we're ready for the test!

I won't write about configurations in this post. I'm assuming you have Jest and React Testing Library set up and you're ready to write your test.

I will write each step without repeating any code, and then at the end I'll leave the complete test snippet for you to check.

Let's start with a few imports. Of course we need to import React first, and we also need render and screen from React Testing Library:

import React from "react";
import { render, screen } from "@testing-library/react";

render allows us to render our component in order to start testing it, and screen provides us with all the queries we need to get elements.

We now need to create our test:

test("Can search for a post using its ID", async () => {});

We import our App component and call the render function.

import App from "../app";

test("Can search for a post using its ID", async () => {
  render(<App />);
});

Great! Our test should be passing. Now we can start using screen to check if our component is displaying what it should.

The Home page

We're in the Home page, so we should see a Welcome message. As this is is text, we can use getByText query. We get that element and then wrap it in an expect statement, expecting that it exists in the document.

expect(screen.getByText(/welcome/i)).toBeInTheDocument();

It's always a good idea to use regular expressions for your text content, and ignore cases. First, your users doesn't care about text cases. And second, if it's a phrase, you may slightly change your words in the future, but you'll always keep a few important ones. Your test should be looking for them, as they will always be there.

Let's see an example of that. In our home page we have an h2 element that says Search for a post by its ID. We could totally do this, and it would work:

expect(screen.getByText("Search for a post by its ID")).toBeInTheDocument();

But what if the next week we change that phrase to Here you can search for a post. The only thing you need is its ID? Of course, now our test would be broken! A better way to write this statement would be this one:

expect(screen.getByText(/search.*post.*id/i)).toBeInTheDocument();

That's perfect! We know that we have three important words that will always be there (search, post and id). With this statement, the test wouldn't break if we changed our phrase as we said before.

The last thing we need to check in our Home page is the Submit button, which should be there but be disabled.

expect(screen.getByText(/submit/i)).toBeDisabled();

Searching for a post

Our Home page is rendering correctly and has all the user needs to search for a post. We need to simulate the user typing in our input field, and React Testing Library has our backs.

We need to import the user-event module:

import user from "@testing-library/user-event";

But before we can simulate the user typing in the input field, we need to get that element. A good practice when testing forms is to get elements by their label. This way we can also check if the label and the input field are associated correctly, which is important for accessibility.

So let's use the getByLabelText query to get that input:

screen.getByLabelText(/post id/i);

And now we are ready to simulate the user typing in it, using the user-event module:

user.type(screen.getByLabelText(/post id/i), "1");

Great! To finish the user interaction, we need to click the Submit button, which we expect to be enabled now.

const submitButton = screen.getByText(/submit/i);
expect(submitButton).toBeEnabled();
user.click(submitButton);

Landing on the Post page

Now that we clicked the submit button, we should navigate to the Post page. The first thing we should see there is a Loading... message, so let's get that.

screen.getByText(/loading/i);

But if you write that, you'll see that the test won't pass:

When this happens, we need to use find* queries, along with await. The test will then wait until the loading message shows up.

await screen.findByText(/loading/i);

Perfect! Now the test is passing.

Mocking HTTP requests

The next thing that happens in our application is that an HTTP request is fired to the API to get the post details. We don't want to fire an actual request in our test, so we need to mock it.

First of all, right after our imports, let's mock the api module using jest:

jest.mock("../api");

And now we can import the module as a mocked version of it:

import { fetchPost as mockFetchPost } from "../api";

In our test, let's create a mock post, the object that our fake request will return when resolved:

const mockPost = {
  id: "1",
  title: "Post Title",
  body: "Post Body",
};

And then instruct our mock function to return that object when called:

mockFetchPost.mockResolvedValueOnce(mockPost);

We can also make a small enhancement to use this mock post object when we simulate the user typing in the input field:

user.type(screen.getByLabelText(/post id/i), mockPost.id);

Perfect! Everything is set up and we can now continue with our test.

Wrapping up our test

First of all we should check that our mock function is called, and that it's called just once:

expect(mockFetchPost).toHaveBeenCalledTimes(1);

And also that it is called with the mock post id we defined:

expect(mockFetchPost).toHaveBeenCalledWith(mockPost.id);

Now let's check that the actual post information is displayed on the screen for the user:

expect(screen.getByText(mockPost.title)).toBeInTheDocument();
expect(screen.getByText(mockPost.body)).toBeInTheDocument();

The only thing left to test is the link back home. First we click it:

user.click(screen.getByText(/back.*home/i));

And then we should be in the Home page:

await screen.findByText(/welcome/i);

We're done! This is the complete test:

import React from "react";
import { render, screen } from "@testing-library/react";
import user from "@testing-library/user-event";
import { fetchPost as mockFetchPost } from "../api";
import App from "../app";

jest.mock("../api");

test("Can search for a post using its ID", async () => {
  const mockPost = {
    id: "1",
    title: "Post Title",
    body: "Post Body",
  };
  mockFetchPost.mockResolvedValueOnce(mockPost);
  render(<App />);

  expect(screen.getByText(/submit/i)).toBeDisabled();
  expect(screen.getByText(/welcome/i)).toBeInTheDocument();
  expect(screen.getByText(/search.*post.*id/i)).toBeInTheDocument();

  user.type(screen.getByLabelText(/post id/i), mockPost.id);
  const submitButton = screen.getByText(/submit/i);
  expect(submitButton).toBeEnabled();
  user.click(submitButton);

  await screen.findByText(/loading/i);
  expect(mockFetchPost).toHaveBeenCalledWith(mockPost.id);
  expect(mockFetchPost).toHaveBeenCalledTimes(1);
  expect(screen.getByText(mockPost.title)).toBeInTheDocument();
  expect(screen.getByText(mockPost.body)).toBeInTheDocument();

  user.click(screen.getByText(/back.*home/i));
  await screen.findByText(/welcome/i);
});

That's it!

We tested the happy path of searching for a post, navigating to a different page, waiting for it to load, seeing the post information on the screen and navigating back to the home page. It was easy, wasn't it?

Of course there are more things to test, even in this small application. I hope this was useful and that you start writing a lot of long, integration tests for your applications.

The 3 essentials to get started with styled-components

Franco D'Alessio — Sun, 10 May 2020 19:18:20 +0000

This post was originally posted in my personal site.

I love styled-components. I use this library for all my personal projects (including my personal site). It's very powerful and also very easy to use. In this article I'm going to explain the 3 main things you can do with styled-components so you can start using it right away.

But first... What exactly is styled-components?

"styled-components is the result of wondering how we could enhance CSS for styling React component systems"

styled-components is a library that allows you to write actual CSS code to style your components, removing the mapping between components and styles. It uses tagged template literals and CSS. That's it.

And this library does everything else for you:

It keeps track of which components are rendered and injects their styles.
It uses code splitting so your users load the least amount of code necessary.
It generates unique class names for your styles, so you don't have to worry about duplications or overlaps.
It makes obvious which styles you are not using (because they are tied to a specific component), so you can easily delete them. This is usually hard when working with CSS.
It automatically prefixes your CSS for it to work with different vendors. You can just write your CSS to the current standard and styled-components will handle the rest.

Everything sounds great, but you may be thinking that writing CSS is not enough for you, that you need dynamic styles. Well, don't worry, styled-components allows you to style components based on props or global themes very easily.

Are you ready to start with it? I promise it'll be very easy! Let's see the 3 essential things you can do with this library.

You can find all the code we'll explain in this CodeSandbox.

1- Create and use your first styled component

First, you need to install the library:

npm i --save styled-components

Now let's say we want to create a Home page where we display a title in the center of the screen. Something like this:

Very simple. We need a div and an h1 tag. The div would have this CSS code:

display: flex;
flex-direction: column;
justify-content: center;
align-items: center;
height: 100vh;

And let's say we want the h1 to be underlined:

text-decoration: underline;

Let's do it with styled-components!

In order to keep the code well structured, let's create a components/Home folder, and two files inside of it: index.js and styles.js.

Our styles file is where we will create our styled components.

Let's start by importing the library:

import styled from "styled-components";

Now, to create a styled component, we need to write style. and then the HTML tag we want to style. In this case, we first need a div, so let's start with that. Also, let's save that component in a variable and export it, so we can later import it from our index file.

export const Home = styled.div``;

The only thing left is to write our styles! And since we can write regular CSS within the backticks, it's very easy:

export const Home = styled.div`
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
  height: 100vh;
`;

Congratulations! You've now written your first styled component! 🎉

Let's go ahead and also add our Title component, which will be a styled h1 tag. The whole styles file will end up looking like this:

import styled from "styled-components";

export const Home = styled.div`
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
  height: 100vh;
`;

export const Title = styled.h1`
  text-decoration: underline;
`;

Great! Now we need to use these components. In order to do that, we need to import them from our index files.

We could do this:

import React from "react";
import { Home, Title } from "./styles";

export default function Home() {
  return...
}

But note that I now have two components named Home, so this will just not work. One option is to assign different names to your styled components. Instead of calling it Home, you can call it Wrapper, or Container, or something like that.

A lot of people take this approach, and it works. But personally I don't like it. I want to be able to name my styled component the same as the parent component. Fortunately, a lot of people think the same, so someone came up with this other approach, which is the one I like:

import React from "react";
import * as S from "./styles";

We can import all of our styled components as a variable called S, and then we are able to render them using that variable. Remember that styled components are just like regular components, so you render them using JSX just as usual:

import React from "react";
import * as S from "./styles";

export default function Home() {
  return (
    <S.Home>
      <S.Title>This is the Home page</S.Title>
    </S.Home>
  );
}

We access our styled components writing S. and then the name of the component. I love this approach because now I can call my styled component Home, and also with a quick look I can tell which of the returned components are in fact styled components (all of them in this case, but that may not be the case for longer, more complex components).

Nesting styles

Before going to step 2, a quick note on nesting. You can nest styles just like you do with SASS. In this case, we could get rid of the Title component, for example. We can just add styles for all h1 existing within our Home component:

import styled from "styled-components";

export const Home = styled.div`
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
  height: 100vh;

  h1 {
    text-decoration: underline;
  }
`;

And if we change our parent component as well...

import React from "react";
import * as S from "./styles";

export default function Home() {
  return (
    <S.Home>
      <h1>This is the Home page</h1>
    </S.Home>
  );
}

This will work just fine. It doesn't always make sense to nest styles, but keep in mind that you can do it and you may not need to create a new component.

2- Use props for dynamic styling

Remember that styled components are just components, so they can receive props. And that props can be useful to dynamically change the styles.

Our example is very simple, but let's say we want to set the color of our title text based on a prop named titleColor.

First, let's pass that prop when we render our Title styled component:

import React from "react";
import * as S from "./styles";

export default function Home() {
  return (
    <S.Home>
      <S.Title titleColor="blue">This is the Home page</S.Title>
    </S.Home>
  );
}

And now let's use that prop to change the text color. We need to use ${} to get access to the props. It's very simple:

export const Title = styled.h1`
  text-decoration: underline;
  color: ${prop => prop.titleColor};
`;

That will make the text blue:

You can also use props for conditional styling. For example, let's say we pass a small prop:

import React from "react";
import * as S from "./styles";

export default function Home() {
  return (
    <S.Home>
      <S.Title titleColor="blue" small>
        This is the Home page
      </S.Title>
    </S.Home>
  );
}

If it's there, we want to make the text smaller. But if it's not, we want the text size to be the regular size.

export const Title = styled.h1`
  text-decoration: underline;
  color: ${prop => prop.titleColor};
  font-size: ${prop => prop.small && "1.25rem"};
`;

Awesome! You know now how to dynamically style components based on props.

3- Create global styles

Creating styled components is great, but sometimes we need global styles. You may want to apply styles using tags as selectors. For example, let's say we want to change the background color of our body.

Fortunately styled-components makes this very simple. Start by importing createGlobalStyle:

import { createGlobalStyle } from "styled-components";

Write your global styles:

const GlobalStyle = createGlobalStyle`
  body {
    background: lightblue;
  }
`;

And then place this component at the top level of your application, in my case my index.js file:

import React from "react";
import ReactDOM from "react-dom";
import { createGlobalStyle } from "styled-components";

import App from "./App";

const GlobalStyles = createGlobalStyle`
  body {
    background: lightblue;
  }
`;

const rootElement = document.getElementById("root");
ReactDOM.render(
  <>
    <GlobalStyles />
    <App />
  </>,
  rootElement
);

And that's it! That will change the background color:

If you want, you can also use props to dynamically change global styles (for example, if you have a light and a dark theme in your application).

That's it!

I hope this post was useful. You now know the essentials to get started with styled-components. Of course, there's more to it, so be sure to check the official documentation.

Thanks for reading ❤️

Never call a React function component

Franco D'Alessio — Fri, 01 May 2020 18:55:19 +0000

When we write React code, we use JSX to create React elements. In case you don’t know, JSX is an extension to Javascript to support syntax that looks like the HTML code you would write to create DOM elements.

JSX allows us to create a React element by just writing this:

const element = <div>Hello World</div>;

As the browser does not understand JSX natively, Babel then converts the JSX syntax using react.createElement API.

If you want to know more about JSX and React elements, you can check this post.

Then we have Components

React allows us to group React elements and create components. They let you split the UI into independent, reusable pieces, and think about each piece in isolation.

Conceptually, components are like JavaScript functions. They return React elements describing what should appear on the screen.

As you may already know, a component can be written as a class…

import React from "react";

export default class Component extends React.Component {  
  render() {  
    return <h1>Hello World</h1>;  
  }  
}

…or as a function:

import React from "react";

export default function Component() {  
  return <h1>Hello World</h1>  
}

But when it comes to rendering a component, you always write the same thing, both for classes and function components:

...  
return <Component />;

You render your components using JSX syntax. And this works just fine.

But if you have a function component, can’t you just call the function?

Well, you can, but weird things will happen. Let’s take a look.

Let’s start with a basic app

Our example application will consist of two components: App and Item. The App component will render a list of items, and each item is an input field. There is also a button which allows us to add a new item to the list.

import React, { useState } from "react";  

import Item from "./Item";import "./styles.css";

export default function App() {  
  const [list, setList] = useState([0]);  
  const addItem = () => setList([...list, list.length]);  

  return (  
    <div className="App">  
      <button onClick={addItem}>Add Item</button>  
      <h1>This is the list:</h1>  
      {list.map(_ => Item())}  
    </div>  
  );  
}

Please note that inside the map we use to render the list items, we are calling the Item component as a function: Item().

Our Item component is just an input field:

import React, { useState } from "react";  

import "./styles.css";

export default function Item() {  
  const text, setText = useState();  
  const handleChange = e => setText(e.target.value);  
  return <input value={text} onChange={handleChange} />;  
}

Please also note that both of our components are using the useState hook. This is important.

Here is the finished app so you can play with it:

You may have noticed there is a warning because we are not passing the key prop for our Item components.The key prop is important, but not the issue I want to talk about here.

Go ahead and click the Add Item button. You should get this error:

Ok, so we know that calling a function component produces some weird error related to Hooks, but what is it exactly? 🤔

Understanding the problem

If you check the console, you will find more information:

Warning: React has detected a change in the order of Hooks called by App. This will lead to bugs and errors if not fixed. For more information, read the Rules of Hooks: [https://fb.me/rules-of-hooks](https://fb.me/rules-of-hooks)  

   Previous render            Next render  
   ------------------------------------------------------  
1\. useState                   useState  
2\. useState                   useState  
3\. undefined                  useState  
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  

    in App (at src/index.js:9)  
    in StrictMode (at src/index.js:8)

There are multiple rules for Hooks, and an important one is this one:

You need to make sure that the Hooks are always called the same number of times for a given component.

Do you understand the problem now?

The way we’re calling Item, is not a component at all, but a function. React cannot associate any useState calls to the Item function, just because it’s not rendered as a component.

So the useState call that should be associated to Item, is actually associated with App. Now the error message “Rendered more hooks than the previous render” finally makes sense.

This is the reason we use JSX to render our components, even if they are function components. That way, React can register any Hooks that are used in a component, with the instance of that component.

Ok, got it. But why the app works just fine if you don’t press the button?

You’ve probably noticed that when the app starts, it works just fine. You can even write in the input field and you won’t see any error.

This is because the App component is not being re-rendered. Once we click the button to add a new item, App is re-rendered and then React notices that the number of Hooks calls doesn’t match with the one of the previous render.

So there will be cases in which you won’t see an error, but doing this is still wrong. In our example, at the beginning it works, but the useState call of Item is being associated to App. This is wrong, and it can make your app behave in unexpected ways as you make changes.

That’s it!

I hope this was useful! Thanks for reading ❤️

The difference between Classes and Function components in React

Franco D'Alessio — Wed, 22 Apr 2020 01:21:20 +0000

In the early days of React, Classes were the only way to have functionality in your components (like state). You’d only use Functions for dumb components which only displayed stuff.

This is no longer true, because we now have React Hooks and they allow us to have in Function components the same functionality we used to have with Classes.

However, there is one key difference, that not everyone is aware of 🔮

Let’s start with a simple example

The best way to understand this concept is by seeing it in action.

Let’s create a simple app where you can select a Simpsons’ character from a list. Then when you press a button, an alert will show a greeting to that character after 4 seconds.

We will create the SayHi component as a Class and also as a Function, to see the difference.

Our two SayHi components

First, let’s write our Function component:

import React from "react";

const SayHiFunction = ({ name }) => {

  const handleClick = () => {
    setTimeout(showAlert, 4000);
  };

  const showAlert = () => {
    alert(`Hello ${name}!`);
  };

  return (
    <div>
      <button onClick={handleClick}>
        Say Hi with Function
      </button>
    </div>
  );
};

export default SayHiFunction;

As you can see, it’s a very simple component. It receives name as a prop, and then when you click the button, a timeout is set to show the alert after 4 seconds.

Now let’s transform this Function into a Class:

import React, { Component } from "react";

class SayHiClass extends Component {

  handleClick = () => {
    setTimeout(this.showAlert, 4000);
  };

  showAlert = () => {
    alert(`Hello ${this.props.name}!`);
  };

  render() {
    return (
      <div>
        <button onClick={this.handleClick}>
          Say Hi with Class
        </button>
      </div>
    );
  }
}

export default SayHiClass;

Pretty easy, right? I’m sure almost anyone with some React knowledge would be able to do this transformation.

You can play with the app here:

However, this two components will not behave the same 😕

So what’s the difference?! 😠

Ok, the important part. Let’s do this:

Select “Marge” from the list
Press the button
Change the character to “Homer” before 4 seconds pass

What do you expect to happen? Do you expect the alert to say “Hello Marge” or “Hello Homer”?

Again, right now the important thing is not what you think will happen, but what would you expect to happen in this case.

Of course, we would expect to see “Hello Marge”. That was the selected character when we pressed the button.

Now that we’re on the same page on that, what do you think will happen?

Let’s take a look at the Function component first:

Good! It behaves as we expected and the alert says “Hello Marge”.

Let’s try the Class component now:

Mmm, that was not what we expected. We changed the selected character after pressing the button, and the alert message also changed 🤔

What the f*%! happened?

Well, our two components are not the same. Of course, one is a Class and the other is a Function, but we also made a mistake when we transformed the Function into a Class.

The example seemed obvious and straightforward, and that’s the transformation most people would do. It’s common to think those two pieces of code are equivalent. However, it’s wrong because of the main difference between Classes and Function components:

Function components capture the rendered values.

What does that mean?

Let’s analyze our example to understand this.

When we used the Class component, the alert message changed after we changed the selected character.

That happens because our method is reading from this.props.name.

But props are immutable in React, that’s not the issue.

It’s true, props are immutable, but… this is mutable. And it makes sense, because React mutates this over time so you can read the fresh version in render and lifecycle methods.

So in our example, by changing the selected character the second time, we re-render the component, so this.props is updated. The method is reading from the latest, newest props.

That’s a problem because we weren’t expecting that. We would expect our event handlers to be “linked” to a particular render, with particular props.

By setting a timeout whose callback reads this.props, we’re making that impossible. Our callback will not be “linked” to a particular render, so it doesn’t know what the “correct” props are.

We don’t have this issue with the Function component because, once again:

Function components capture the rendered values.

That means that even if we change the character a second time, the method will display the alert using the selected character when the button was pressed, because that value was captured. Unlike this, the props are immutable so the object is never mutated by React.

When the parent component renders SayHiFunction with different props, React will call the SayHiFunction again. But the event handler we already clicked is “linked” to the previous render with its own name value and the showAlert callback that reads it.

So Classes are useless?

No! Not at all. Classes are fine, we’re having a bug here because our implementation is incorrect, different from the original function component.

If you don’t want to use a Function component, there are many ways to fix this issue. For example, you could do this:

import React, { Component } from "react";

class SayHiClass extends Component {

  handleClick = () => {
    const { name } = this.props;
    setTimeout(() => this.showAlert(name), 4000);
  };

  showAlert = (name) => {
    alert(`Hello ${name}!`);
  };

  render() {
    return (
      <div>
        <button onClick={this.handleClick}>
          Say Hi with Class
        </button>
      </div>
    );
  }
}

export default SayHiClass;

Our props were getting “lost” before, so in this case we are reading and capturing them early during the event.

Again, this is just one way of fixing it, there are many others but that’s not the focus of this post.

That’s it!

I hope this post was useful and now you understand the main key difference between Classes and Function components.

Thanks for reading ❤️

Understanding React's useEffect Hook

Franco D'Alessio — Wed, 15 Apr 2020 02:42:04 +0000

Photo by Wes Hicks on Unsplash

React Hooks are awesome and definitely make our lives as React developers much easier. In case you don’t know what they are, Hooks were introduced in React 16.8.0, and they let you use state and other React features without writing a class 💃

The most important thing is that Hooks don’t replace your knowledge of React concepts. Instead, Hooks provide a more direct API to the React concepts you already know: props, state, context, refs, and lifecycle.

Note: if you’re new to React, learn Hooks and functional components first. Only after that, learn the old way of doing things (class components)

This post is not about Hooks in general, but if you want to know more about them and why they exist, the best thing you can do is watching the official React Hooks presentation:

If you haven’t learned Hooks yet, you should do it as soon as possible. And if you’ve been reading about them, you may be a bit confused about the useEffect Hook 😕

The useEffect Hook

Plain and simple, useEffect lets you perform side effects in function components.

Ok… But what are side effects? 😒

Side effects are all the operations that affect your component and can’t be done during rendering. Things like fetching data, subscriptions or manually changing the DOM are all examples of side effects, and things you’ve most likely done in the past.

What are the benefits? ✅

Avoiding duplication of code
Bringing related code closer together
Avoiding bugs
Separating separate effects by their purpose, something impossible to do with classes

All these benefits will become clearer once you read the following explanation and examples.

The old way of doing things 🔙

In the past, when we only had class components, we handled side effects using the lifecycle methods.

For example, among other stuff, we used componentDidMount to fetch data from APIs, componentDidUpdate to send data when something changed, and componentWillUnmount to unsubscribe from events.

class MyComponent extends React.Component {
  constructor() {}
  componentDidMount() {
    // Fetch data from API
  }
  componentDidUpdate(prevProps, prevState) {
    // Send data when props change
  }
  componentWillUnmount() {
    // Unsubscribe from events before the component is removed
  }
  render() {}
}

useEffect combines all those three methods into one convenient API.

A paradigm shift ⚡️

To really understanduseEffect, we need to change the way we think about components and state changes.

When we used classes, we had to think about when. The question we needed to answer was when does this effect run?

useEffect is different.

It exists to synchronize the state of the world with the state of the component.

So the question now is: which state does this effect synchronize with?

You need to stop thinking about lifecycles and time, and start thinking about state and synchronization with the DOM.

How does useEffect work? ⚙️

By default, useEffect runs after every render, including the first one. React guarantees the DOM has been updated by the time it runs the effects.

When you use useEffect, you’re telling React that your component needs to do something after rendering. You pass a function (the “effect”), and React will remember it and call it later, after performing the DOM updates.

function MyComponent() {
  React.useEffect(() => {
    // this side effect will run after every render
  });
  return ...
}

What about cleanups? 🗑️

We said earlier that useEffectalso “replaces” componentWillUnmount method.

A common use case for this method is to unsubscribe from events before the component is finally unmounted.

To replicate that behavior with useEffect, you just need to return a function. React will take care of everything and run it when it is time to clean up.

function MyComponent() {
  React.useEffect(() => {
    // this side effect will run after every render
    return function cleanup() {
      // this code will run before the component is unmounted
    }
  });

  return ...
}

The dependencies array

Of course, running all effects on every render might lead to performance issues (and even infinite loops in some cases).

However, React doesn’t know what your function does before calling it. It may seem obvious to you that it’s not necessary to run some effect function again, but not for React.

So to fix that, you need to tell React. You can provide a second argument to useEffect, which is a dependencies array.

Think of it like telling React “This function only needs to run if X is updated”. If each of these values is the same between the current and the previous time this effect ran, there’s nothing to synchronize and React will skip the effect.

function MyComponent() {
  React.useEffect(() => {
    // this side effect will run only when value1 changes
  }, [value1]);

  return ...
}

If you pass an empty array as second argument, the function will run just once, after the first render. This tells React that your effect doesn’t depend on any values from props or state, so it never needs to re-run.

function MyComponent() {
  React.useEffect(() => {
    // this side effect will run just once, after the first render
  }, []);

  return ...
}

So a summary would be:

No dependencies array: the function runs after every render
Empty dependencies array: the function runs only after the first render
Dependencies array with some values: the function runs only if any of those values change

If you use an empty dependencies array, don’t do it because you think “I need this to run just once, after the first render”; do it because you know that the stuff it’s doing will never get stale.

function MyComponent() {
  React.useEffect(() => {
    // this side effect will run just once, after the first render
  }, []);
  React.useEffect(() => {
    // this side effect will run only when value1 changes
  }, [value1]);
  React.useEffect(() => {
    // this side effect will run after every render
  });
  return ...
}

Be careful with your dependencies array ⚠️

If you use the dependencies array, make sure it includes all values from the component scope (such as props and state) that change over time and that are used by the effect. It’s very common to forget a value or to think that you don’t need it in the array. If you do that, you will produce bugs, because your code will reference stale values from previous renders.

To help with this, always use eslint-plugin-react-hooks.

You can use multiple effects! 😏

You can calluseEffect as many times as you want. In fact, it’s recommended to call it several times, in order to separate concerns.

For example, there are some things that you need to do only after the first render and never again, and other things that need to happen after every render.

function MyComponent() {
  React.useEffect(() => {
    // I need to do this just once, after the first render
  }, []);
  React.useEffect(() => {
    // But this other thing needs to be done after every render
  });
  return ...
}

Goodbye code duplication! 👋🏼

useEffect helps to avoid code duplication in a very common case.

Let’s say you need to run an effect after every render. It doesn’t matter if the component has just been mounted or it has just been updated, you need to perform certain side effect in both cases.

To do this with classes you need to duplicate code:

class Mycomponent extends React.Component {
  constructor(props) {}

  componentDidMount() {
    // do something
  }  
  componentDidUpdate() {    
    // do the same thing again
  }
  render() {
    return ...
  }
}

But with useEffect, the code will run after every render, including the first one.

function MyComponent() {
  React.useEffect(() => {
    // do something
  });
  return ...
}

Keep related code together 👫

Let’s say we have a component where we need to subscribe to an event, and then unsubscribe from it before the component is removed. Here’s how we would do that with classes:

class Mycomponent extends React.Component {
  constructor(props) {}
  componentDidMount() {
    // susbscribe to event X
  }
  componentWillUnmount() {    
    // unsubscribe from event X
  }
  render() {
    return ...
  }
}

Note how lifecycle methods force us to split this logic, even though the code in both of them is related to the same effect.

With useEffect, we can keep this code together in the same function:

function MyComponent() {
  useEffect(() => {
    // subscribe to event X
    return function cleanup() {       
      // unsubscribe from event X
    };  
  });

  return ...
}

useEffect(fn, []) vs. componentDidMount 🥊

For what I’ve told you so far, you may think that’s right. I’ve told you that if the dependencies array is empty, your effect will run only after the first render, which is how componentDidMount works, right?

Well, there is a difference.

useEffect runs after the paint has been committed to the screen. componentDidMount runs before the paint has been commited to the screen.

For most cases, you won’t need to worry about this, because most of your effects will be asynchronous.

But there are some things that require that you read the DOM and synchronously re-render. For example, if you need to measure the layout.

For these cases, there is a separate useLayoutEffect Hook with an API identical to useEffect.

That’s all!

useEffect can be a little tricky, and it requires some practice. I hope this guide helps, and always remember: don’t think about lifecycles, think about synchronizing side effects to state.

If you need more information, you can check React’s official documentation or this awesome guide by Dan Abramov.

Thanks for reading ❤️

Basic accessibility for your HTML forms

Franco D'Alessio — Sat, 11 Apr 2020 01:21:38 +0000

Photo by Glenn Carstens-Peters on Unsplash

Today I want to write about a simple, yet powerful element you must include when building an HTML form: labels.

You probably know what a label is. It tells the user what the field is all about. For example, when you see this:

You know that you’re supposed to write your name in this input field.

You can write that code in two different ways. This is one option:

Name:
<input type="text" />

And this is the second option you have:

<label>Name: </label>
<input type="text" />

For a person who can see, there is no difference. Both pieces of code will display the same on the screen.

But blind users use a screen reader, and without the label tag, they won’t know what the input expects them to write 😕

So now we know that we need to use label tags for every field in our forms. These are the elements that use explicitly associated labels:

input type="text"
input type="checkbox"
input type="radio"
input type="file"
input type="password"
textarea
select

But it’s not enough… 🛑

Just because we added a label tag it doesn’t mean our form is ready. We’re missing the most important part, which is associating the label to the input element.

These are the two best ways to do it:

1- Put the input inside the label tag

<label>
  Name
  <input type="text" />
</label>

2- Add "for" attribute on the label and "id" attribute on the input

<label for="last-name">Last name:</label>
<input id="last-name" type="text" />

The value must be the same for both attributes.

There is a third way of associating a label to the input, which is this one:

<input aria-label="username" />

This works for screen readers, but it removes the visual label from the screen. This is not good because the users won’t know what they are supposed to write in the input.

You may think that adding a placeholder can fix the issue, but only partially. When you type, the placeholder disappears. Once you end filling out the form and you want to check what you wrote, you’ve again the same problem: you don’t know what each field is about.

So it’s better to use one of the first two options. When you successfully associate a label with an input element, the label area becomes clickable as well 🎉 This is a good way to check if you did a good job: click the label and the input should be focused.

One more thing

When you are done building a form, always check if you can fill all the fields by just using your keyboard.

This seems obvious, but a lot of forms (and I mean a lot) are impossible to use without a mouse. You need to think there are lots of people that unfortunately cannot use a mouse, and therefore they won’t be able to fill out your form.

That’s all!

Thanks for reading ❤️

Understanding React elements and JSX

Franco D'Alessio — Fri, 10 Apr 2020 17:41:04 +0000

Photo by Ferenc Almasi on Unsplash

Let’s start by writing a simple piece of code to display a “Hello World” message, using just vanilla Javascript and browser APIs.

First, let’s create a root div in our body section:



<body>
  <div id="root"></div>
</body>

We will now create a new div with the Hello World message and append it to our root div using Javascript.

We need to get that root div element first:



const rootElement = document.getElementById('root');

Then create a new div and add the text content:



const element = document.createElement('div');
element.textContent = 'Hello World';

And finally append this new child element to the root element:



rootElement.appendChild(element);

That’s all we need to display a Hello World message. Here is the final code:

Let’s do the same with React

React controls and updates the DOM using the same APIs we used in our previous example. But instead of creating DOM elements, we’ll create React elements. react-dom will take care of converting them into DOM elements and putting them into the page.

What is a React element?

Think about React elements as a description of what you see on the screen. React reads these objects and uses them to construct the DOM and keep it up to date.

Don’t confuse React elements with components. Elements are what components are “made of”, and you must first understand what they are before jumping ahead into components.

The createElement API

For this first React example we’ll use React’s createElement API.

We need to get React on the page. We'll add react and react-dom directly from unpkg as script tags.

Then, instead of creating a div element we create a React element. The API for react.createElement is:



function createElement(elementType, props, ...children) {}

We don’t have any props in our example, so we’d create our element like this:



const element = React.createElement("div", null, 'Hello World');

The text Hello World is our element’s child.

We can see this React element by logging it to the console:

We don’t get a DOM element, but an object. Remember we said earlier that React elements are objects that describe what you see on the screen.

You can see that children is actually inside the props object.

These two lines are equivalent and both correct:



const element = React.createElement("div", null, 'Hello World');
const element = React.createElement("div", {children: 'Hello World'});

You can pass the children inside the props object or as the third parameter of the function.

Ok, we’ve got our React element. Now what?

Instead of appending this element to the root element, as we did in the first example with our DOM element, we’ll let react-dom handle all that:



ReactDOM.render(element, rootElement);

The end result will be the same as the first example. This is the final code:

Finally, let’s use JSX! 🚀

This react.createElement syntax works, but is not the best. Fortunately, we have another option, which is also the standard way the community uses to create React elements.

What is JSX? 🤔

JSX is an extension to Javascript to support syntax that looks like the HTML code you would write to create these DOM elements.

So we can create our element by just doing this:



const element = <div>Hello World</div>;

Sweet, right?

Why JSX?

React doesn’t require you to use JSX. You can use the createElement API and everything will work in the same way.

However, JSX is of great help. React is based on the principle that rendering logic is coupled with UI logic. Instead of separating them by putting markup and logic in separate files, React uses components that contain both.

Using JSX is helpful because it allows you to easily work with UI inside Javascript code.

JSX is awesome! But we still have a problem…

The browser does not understand JSX natively, so it needs to be compiled. That’s where Babel comes in. It will convert JSX syntax to something the browser can understand.

What do you think that will be?

Exactly: it will use react.createElement API.

You can try this yourself in the Babel’s website.

Adding props

In the last example, the second argument to createElement is null because we have no props.

We can include a className and see how Babel translates it to be the second argument of the createElement function:

Adding children

We can also add more children. Right now, the only child is the Hello World text, but we can add more:

You can see that now the third argument of the createElement function is not just a string. Instead it’s a second React element of type p, which has the Hello World string text as its child.

The power of JSX 💪

With JSX you can do more than just creating React elements. Let’s take a look at everything JSX has to offer.

Embedding expressions

Using curly braces, you can embed any Javascript expression inside JSX.

For example, you can do this:



const name = 'John';
const element = <div>Hello {name}</div>
ReactDOM.render(
 element,
 document.getElementById('root')
);

And Hello John will be displayed on the page.

But it doesn’t have to be just a static string value, you can embed any Javascript expression:



const element = <div>2+2 = {2+2}</div>
ReactDOM.render(
 element,
 document.getElementById('root')
);

In this case, 2+2 = 4 will be displayed on the page.

JSX is an expression

We know that JSX will be compiled to be a react.createElement function, and that function will return an object.

That means that we can assign JSX to variables:



const element = <div>Hello World</div>

Or, for example, return JSX from functions:



const getAgeDescription = (age) => {
  if (age < 50) {
    return <h1>You're young</h1>;
  } 
  return <h1>You're old</h1>;
}

Specifying attributes

You can use quotes to specify string literals as attributes:



const element = <img src='http://xyz.com/img.jpg'></img>;

Or curly braces to embed a Javascript expression:



const user = { name: 'John', profileImgUrl: 'http://xyz.com/img.jpg' };
const element = <img src={user.profileImgUrl}></img>;

JSX uses camelCase for attributes, and there’re some changes you have to keep in mind. As some words are reserved by Javascript, some attributes change its name when using JSX.

For example, you don’t use class in JSX, but className. You don’t use for in a label element, you use htmlFor .

To read more about these exceptions and all the accepted attributes in JSX you can check the official documentation.

Self-closing tags

If an element doesn’t have any children, you can close it with />:



const element = <img src={user.profileImgUrl} />;

That’s all!

Understanding how JSX is compiled is important because it will make you more effective at using JSX. I encourage you to take you React code to the Babel website to see how it is compiled and how it looks using the createElement API.

I’ll leave this here. There are a lot of things I could continue writing about (rendering, components, etc.), but I’ll do so in separate articles. JSX is an important concept and you should understand it well before moving on to other stuff.

Thanks for reading ❤️

Understanding the importance of the key prop in React 🗝

Franco D'Alessio — Wed, 01 Apr 2020 22:46:14 +0000

Photo by Shane Avery on Unsplash

If you’ve written some React code, you’ve most probably seen this warning:

Almost every React application displays an array list of some kind using the method map. And React tells us that for each element of that list that we return for rendering, we must provide a unique key prop.

But do you know why it’s necessary?

Why does React need this key prop? 🔑

The official documentation clarifies this perfectly:

Keys help React identify which items have changed, are added, or are removed. Keys should be given to the elements inside the array to give the elements a stable identity.

When the state of your component changes, the render function will return a new tree of React elements, different to the previous/current one. React needs to figure out what are the differences to efficiently update the UI with the most recent changes. This process of matching both element trees is called reconciliation.

You can read more about React’s diffing algorithm here, but the important thing for us are the lists.

So… What’s exactly the problem with lists?

Well, imagine that you render a list and you don’t provide keys for its elements:

<li>Item 1</li>
<li>Item 2</li>

Then imagine a new Item 3 is added. The new tree looks like this:

<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>

React now needs to compare these two trees to identify the changes made. And to do that, React iterates over both lists of children at the same time and generates a mutation whenever there’s a difference.

So it will match the first two elements, and generate a mutation for the third one. Good. So far, no problems 👍

Now, imagine that a new item is added, but at the beginning. This is the new tree now:

<li>Item 0</li> // <= New item
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>

Once again, React will iterate, compare and generate mutations where needed.

When comparing the first element of the old tree (Item 1) with the first element of the new tree (Item 0), they are different, so a mutation is generated.

When comparing the second element of the old tree (Item 2) with the second element of the new tree (Item 1), they are different, so a mutation is generated.

And so on… Do you see the problem? React will mutate every child instead of realizing it can keep items 1, 2 and 3 intact. This inefficiency is a problem 😕

Key prop to the rescue!

This is why the key prop is needed, to solve this issue. When children have keys, React uses the key to match children in the old tree with children in the new tree.

<li key={0}>Item 0</li> // <= New item
<li key={1}>Item 1</li>
<li key={2}>Item 2</li>
<li key={3}>Item 3</li>

Now React knows right away that the new item is <li>Item 0</li>and the other items have just moved. 👌

Ok, got it. But will my app break if I don’t use keys? 🤔

It depends. Apart from the warning, your application won’t throw an error, but you may produce bugs if you don’t provide keys. If you change the order of the list items (either by sorting the list or removing an item, for example), weird things will happen. You’ll see it in the following example.

Let’s code to make it clearer

I’ve coded a very simple app where you are presented with a list of emojis and you can rate each of them.

If the app was just that, the absence of keys wouldn’t produce any bug. The list is static and there’s no way the items are reordered.

But to illustrate the problem, I’ve also added the possibility to remove the emojis from the list.

You can play with it here:

If you check the console, you’ll see that React is warning us about not having the key property for our list items.

To see what happens when we don’t provide a key, do the following:

Rate only the 😘 emoji as “Very good”
Delete the 😘 emoji

Do you see the problem now? In case you don’t want to play with the sandbox (or it doesn’t work), here is what happens:

After the deletion, the 🤪 emoji appears rated as “Very good”, which is wrong because we haven’t changed its rating at all 😦

Using index as key

You’ll see that for some simple applications, usually used to teach or explain React concepts, people will use the index as key.

Do you think this solves the problem? 🤔

Spoiler alert: it doesn’t. You can go ahead and try it, but the same bug will be produced.

As component instances are updated and reused based on their key, if the key is an index, moving an item changes it. As a result, the component will be updated in unexpected ways.

So what to do then?

You need to use some unique value as a key. In this case, I’ve included an id field to make it easier. It doesn’t have to be a number, you can use a string if you want. In this case we could even use the emoji itself as key, because each one of them appears only once in the array, but be careful about that.

However, don’t overthink it, because the data you’ll get in a real life application will most likely have a unique id field to identify each element.

If we rewrite our list item element to be like this:

<li className="emoji-item" key={emoji.id}>

Then both the warning in the console and the problem we had at runtime will be gone 🎉

So… What do you think? 😃

Was this useful? I hope it was, and please forgive me (and let me know 🙏) if there is any error in the code.

Thanks for reading ❤️

Creating custom React hooks for a simple To-do list app

Franco D'Alessio — Wed, 01 Apr 2020 13:53:25 +0000

In this post I’m going to do a refactor to a simple To-do list app. The goal is to create some custom hooks so you can see how simple it is.

If you don’t know what hooks are and how awesome they are, it’s a good idea to check the official documentation first

But… Why bother in the first place? 😕

Coding a custom hook provides us with two very clear benefits. First, we can extract common functionality to be reused by several components. We do that with components, so it makes sense to do the same with functions.

And secondly, we get rid of a lot of boilerplate code in our components, which make them cleaner and easier to read.

This two benefits will become clearer when you see the example ✍️

Let’s start with a simple To-do list app ✔️

I’ve coded a very simple app. It allows the user to:

Type a to-do item and add it to the list
See the list
Mark a to-do as completed/uncompleted by clicking on it
Removing a to-do from the list by clicking the red X button next to it

See it in action:

And here is the code:

Now that we’re ready, let’s start building some custom hooks! 🚀

A custom hook to control the input field

Let’s start with a simple one. It’s a good idea to create a hook to manage the state of the input field we have. Why? Because it will be highly reusable; every other component that has a form with input fields will be able to benefit from it.

Right now we’re controlling the input field with this piece of state:

const [todo, setTodo] = React.useState("");

When the value is changed (the user types something) we’re calling this function:

const handleChange = e => {
  setTodo(e.target.value);
};

And onSubmit, after the new to-do is added to the list, we’re cleaning the input field:

setTodo("");

In every component that has an input field, we would need to have these three things. Keep them in mind because we’re going to use these 3 things in our hook.

Creating the new useInput hook

First, start by creating a new folder hooks (just to keep things organized) and create a new file called useInput.js.

The name of every official hook start with the word use, so follow that rule when creating a custom one

You’ve seen that React’s useState hook returns two things: the value and a function to update it. However, it’s not necessary that a hook returns just 2 things.

In fact, we’re making our hook return 3 things:

The value
A function to handle the change (update the value)
A function to reset the value (clean the input)

As for the parameters, our hook function only needs one thing: the initial value.

This is the skeleton of our hook:

function useInput(initialValue) { 
  // Code goes here
  return [state, handleChange, reset];
}
export default useInput;

Now we have to add the body of our function. But actually we’ve already done it! Remember, we’re just extracting the logic from our component.

So we’re going to use the 3 things we enumerated before (and I asked you to keep in mind 😉). The final hook should look like this:

So now we can go ahead and add the hook to our component! 🚀 That includes importing it:

import useInput from './hooks/useInput';

Actually calling it:

const [todo, setTodo, resetTodo] = useInput(“”);

And also get rid of our handleChange function and replace some of the code to use the two functions our hook provides. The component should now look like this:

Better, right? It’s cleaner; not a huge change because our hook is small, but remember that we’ll be able to use this hook in every other component that has an input field 🎉

Let’s build a bigger hook 💪

Ok, so now that we’ve seen how to create a custom hook and how easy it is, let’s create a bigger one.

Our app is really small and doesn’t have a lot of functionality, but it does share a common thing with almost every application, big or small. Can you guess what?

Exactly, it uses a list. Have you ever coded a React application without using an array list? 🤔

It would be great if we could create a hook to handle arrays. That would be useful not only for other components in this application, but also for virtually any other application.

Creating the new useArray hook

We have 3 actions involving our to-do list:

We can add a to-do
We can remove a to-do
We can toggle the completed status of a to-do

Let’s move all that logic to a hook called useArray. As this hook is going to return several functions (plus the list itself) and may even grow in the future, I’m not going to do it return an array as the previous hook. That would mean destructuring a lot of things and wouldn’t look nice.

Instead, I’m going to make our function return an object, containing all we need. There’s no rule saying that you must make your hook return an array, so this is not a problem.

As with the previous hook, let’s begin with the skeleton. We know that we will be receiving the initial value for the list itself and that we’re returning that alongside with the 3 methods we mentioned:

function useArray(initialList) {
  const [list, setList] = useState(initialList);
  return {
    list,
    addItem: () => {},
    removeItem: () => {},
    toggleItem: () => {},
  };
}
export default useArray;

Now we just need to extract those 3 functions from our component and add them to this new hook, which will end up looking like this:

Now for the big moment 🥁 Let’s get rid of all these functions on the component and replace them with our brand new hook:

Now that’s a lot cleaner, right? 😎 And of course, it works the same as before.

We got rid of a lot of code! Our component is definitely easier to read now. And the best part, once again: we’ll be able to use our hook in any other component that handles a list like this.

So… What do you think? 😃

What’s your opinion on custom hooks? Have you ever used it? If you haven’t yet, hopefully you will after reading this!

I hope it was useful and please forgive me (and let me know 🙏) if there is any error in the code.

Thanks for reading ❤️

Speed Matters: Designing for Mobile Performance - A summary

Franco D'Alessio — Mon, 30 Mar 2020 15:38:31 +0000

Awwwards, in collaboration with Google, produced a great eBook called Speed Matters. Designing for Mobile Performance. It explains what mobile web users expect and how they behave, and then provides great insights on how to optimize your sites to provide a better experience.

The cover page of the eBook Awwwards produced in collaboration with Google

This article is a summary of that eBook, which contains the things that I considered to be interesting and useful. Please read the full eBook for more details. On the last pages you’ll also find an extensive list of articles, videos and tools for more information.

The need for speed

53% of mobile site visits are abandoned if the pages take longer than 3 seconds to load.

The need for speed is a research carried out by Google which studies the relation between real and perceived performance by users.

The most important insight this study provides is this one:

Speed matters on the mobile web, but perception of speed is just as important.

How important is speed for users?

Speed was rated as the most important UX factor for users when visiting a website: 75% of them mentioned it 🏆

The list of UX factors considered most important by the users

In general, real downloading speed is quite fast. 7 out of 10 sites loaded in less than 4 seconds, and around 33% loaded in less than 1 second.

Google’s PageSpeed Insights is a great tool where you can test your website and get results for several speed metrics, both for desktop and mobile

Mobile browsing in context

Mobile web browsing mainly happens at home (82% of the total) by people that are relaxed and calmed 😮 This fact was very surprising to me. If someone had asked me, I would have answered the opposite.

Distribution of mobile web browsing by location

Which is not surprising is that in this context, page load speeds are perceived as being faster. For people that are at work or traveling/elsewhere, load times are perceived as being slower.

But even for fast loading sites, 29% of people still don’t actually perceive them as fast 🤔

So what affects the perception of speed?

These are the 4 external factors that affect speed:

Effective use of the site 👆

Web visits where actual speed was slow but felt to be fast tended to be retail sites. We know that long scroll sites are designed to populate the page “above the fold”, giving the impression that the page is complete, even though loading is still ongoing “below the fold”.

This GIF shows how Amazon loads content above the fold first

This can explain some of the distortion between the real and the perceived speed: the difference between the time after which a site can effectively be used vs. the time it takes to fully load. This is a prime example of design thought to optimize the perception of performance.

Age 👴

Younger users are more demanding. Users between 18 and 24 years old only perceived 50% of the sites as fast loading sites. This number goes up to 73% for users between 35 and 44 years old.

State of mind 💆‍♂

As previously said, when users are calm and relaxed, sites are perceived as being faster. In this context around 80% of the sites were perceived as fast loading sites.

When users are feeling rushed or anxious, the perceived speed slows down. In this context only around 40% of the sites were perceived as fast loading sites.

Place of activity 🏠

On the move things feel slower. For people sat down, 75% of the sites were perceived as fast. But for people on the move, only 52% of them. When we’re not at home and need the information as soon as possible, things feel slower.

Outcomes of speed

When perceptions of speed were thought to be fast, a higher percentage of users reported that:

They could achieve their goals (92% vs 73% for slow perceived sites)
They were more likely to return to the website again (95% vs 62% for slow perceived sites)

Speed also significantly impacted brand NPS (Net Promoter Score): an average of 92 points vs 44 for slow perceived sites.

Improve the perception of speed 🏃

Understanding interface response time

Not only the waiting time during loading is important, but also the time that the interface takes to respond to each interaction of the user. If the user has to wait 8 seconds for anything, he/she will most probably abandon the task 😰

Users have less patience when they first enter a site than when they make successive interactions within the same site. Some users will tolerate waiting up to 5 seconds for tasks that are part of the user flow.

First Meaningful Paint and Time to interactive

· First Meaningful Paint is the time required to show something useful in the screen to engage the user.

· Time to interactive is the time required by the browser to finishing building the DOM so the user can begin to interact with the application.

As we already discussed, most retail sites use a very good trick that addresses these two metrics: they produce a quick FMP and prioritize the load of necessary scripts so that the content becomes interactive.

Put the user in active mode

SOME years ago, executives at a Houston airport faced a troubling customer-relations issue. Passengers were lodging an inordinate number of complaints about the long waits at baggage claim. In response, the executives increased the number of baggage handlers working that shift. The plan worked: the average wait fell to eight minutes, well within industry benchmarks. But the complaints persisted.

Puzzled, the airport executives undertook a more careful, on-site analysis. They found that it took passengers a minute to walk from their arrival gates to baggage claim and seven more minutes to get their bags. Roughly 88 percent of their time, in other words, was spent standing around waiting for their bags.

So the airport decided on a new approach: instead of reducing wait times, it moved the arrival gates away from the main terminal and routed bags to the outermost carousel. Passengers now had to walk six times longer to get their bags. Complaints dropped to near zero.

You can see the full story here.

There are two forms of waiting: passive and active. In passive waiting, the user simply watches something loading, without doing anything. When this happens, people overestimate waiting times by 36%.

You want to get people to active mode. Just like in the Houston airport story, you have to occupy users to hack their perception. If you make them wait while interacting with a game or answering a little questionnaire, the same amount of waiting time will feel shorter.

Create instant interactions

Instant feedback from the interface make the experience feel fluid and generate the illusion of continuity. They entertain the user while the “real” action is pushed into the background on a second thread.

Check these UI animations and microinteractions for some prime examples.

Use the right loader ⏳

Use spinners for short waiting times, and progress bars for longer ones.

It can also be more informative to show the length of the remaining waiting time than the percentage of data still to be loaded.

Alitalia does this when you search for a flight

UX Patterns

You can also use the following UX patterns to improve speed perception and minimize time in passive wait.

Preemptive start

It is the realization of the beginning of a task before the user demands it. For example, by showing a questionnaire you distract the user while other assets are loaded.

Other examples are:

Loading assets on login screen
Preload assets on rollover
Preload content on previous states (preload the content of the next screen)
Preload assets while the user is on a multi-step forms

Early completion 🕐

In this case we partially show content that is not yet complete. The most common example is video streaming.

🖼 Other techniques regarding images include:

Progressive images. Images are loaded in successive states. The user can see a low resolution representation of the image that continues downloading.
Placeholders or low-res blurred images like used here in Medium.

Optimistic UI

Optimistic design, which can sometimes be dangerous, is a model where an incomplete task is presented as complete. It is based on the fact that only between 1% and 3% of client requests get a server error 🎉 It helps to create a smooth and interrupted experience for the user.

Only between 1% and 3% of client requests get a server error

A great example of this are Instagram likes. When you like a post, the action appears to be immediate, but in reality it is stored in the database at a later stage.

Smooth and optimized animations

To get a smooth motion, animations must maintain 60fps and each frame needs to be rendered in less than 16ms.

Easing functions

Choosing the right “easing” is decisive to produce a smooth animation. Easing functions are curves that describe the acceleration or deceleration of a motion in a period of time.

The different ease functions curves

Use Ease-out for UI elements
Avoid Ease-in and Ease-in-out with long times. They are perceived as too slow for the users. Use them only for short times
For Ease-out and Ease-in use a duration of between 200–500ms
For Bounce and Elastic effects use a duration of 800–1200ms

Animation optimization

Animate the correct properties 🎯

When using CSS transitions or animations, try to only use opacity and transform properties. All other properties are very slow to animate, especially on mobile devices.

CSS or JS animations?

Use CSS for simple animations, transitions and to animate DOM elements.
Use JS for complex animations, to animate sequences, independent transformations and path animations.

Designing for mobile performance

Content strategy ✍️

Optimization isn’t just about compressing assets, optimizing server architecture or cache. It should begin in the analysis part of the project, where you understand the user path and the way the users will interact with the site. This way you can establish viable goals and design the content based on your target audience behavior and needs.

A very useful tip is to always create a Performance Budget to avoid an excess of unnecessary resources.

The performance budget 💰

Establish a series of limitations based on the analysis of our target, their devices and possible access conditions to the site.

The performance budget should include the following data:

Page weight in kilobytes, including all assets
Percentage assigned to each type of asset (images, CSS, JS, etc.)
Number of HTTP requests
Max time to load over 3G connections

Image strategy 🖼

A very high percentage (around 70%) of a site is composed of images. You really need to understand which graphic material is actually useful or significant for your brand.

Separate your images in these 4 categories:

Navigation and action images
Branding and priority images
Decorative images
Informative images

The first two types are very important and are the images that need to be always present. You need to work on decorative and informative images. While they’re nice to have, they are not critical, so try to replace them whenever possible with alternative designs (color blocks, text, etc.).

Deliver the minimal code needed

Most websites ship all the JavaScript a website needs upfront. This is bad, because all that also needs to be parsed, compiled and executed by the browser. This is especially important when working with mobile devices.

You want to deliver the minimal code to make a page useful upfront. Consider splitting your JS and only serve down the minimal code to make the current page useful for the user. Non-critical code should be lazily loaded in or added on the pages that absolutely need it.

Preload critical resources ❗️

Browsers like Chrome load resources like JS, fonts and images with different priorities. They try to guess what the user’ll need first.

But nobody knows more about your assets than you, the author of the site. You need to know which of them are critical to load early on each page, and design/code them according to that.

Inline critical CSS

Try to put the CSS that you expect the current page to use (critical CSS) inside a style tag in the header section. This allows the browser to paint the page without any network call and therefore it’s super quick.

Eliminate render-blocking resources in above-the-fold content

In web development, the term “above the fold” refers to the portion of a webpage that is visible without scrolling.

Loading contents that are not directly involved in the rendering of this prioritized visible content causes a delay that directly impacts conversion rates and user’s speed perception of the website.

So… What do you think? 😃

I found these insights and tips really interesting and useful. Some of the data was even surprising to me. What are your thoughts? Please leave a comment and let me know!

Thanks for reading ❤️