Important
This article is not a list of questions to expect on an interview and complete answers to them. The point of this post is to show what questions I ask, what I’m looking for in an answer and why there are no bad answers.
If you want a list of “best react interview questions 2018” check out https://github.com/sudheerj/reactjs-interview-questions

Part of my job is performing the so called “technical interviews” during which I evaluate potential candidates that are applying for a “Frontend Developer with React” position.

If you’ve ever Googled “react interview questions” (or any other “[tech] interview questions”) you’ve probably seen countless results of “top 10 react interview questions” which are either outdated or rehash the same “what’s the difference between state and props” or “what’s virtual dom” questions.

Knowing answers to those questions should not be the basis on which the interviewer decides to hire or not. That’s something a candidate needs to know, understand and implement in his daily work. If you’re a candidate being asked those questions either the person interviewing you has no tech background (a HR person or “linkedin headhunter”) or they see this as a formality.

The interview should not be a waste of time. It should give you an idea about the candidate past experience, past knowledge and development opportunities. The candidate should learn about your organisation and project (if possible) and get feedback on his performance vs. your expectations. There should be no bad answers in a job interview (unless the questions is strictly technical) — an answer should give you an insight into the person thought process.

The article is written from the perspective of the person conducting the interview!

Let’s get to know each other

In many cases the interview will be conducted via Skype or other voice (or voice+video) communication platform. Getting to know the potential hire is a good way to get them to open up.

Can you tell me a bit about your previous job, how did you fit in the team? What were your responsibilities?

Knowing what the person did at his previous work place (if he’s allowed to share) is a good way to start. This gives you some basic idea about the previous work experience: soft skills (“I was a sole developer on …”, “I, and my colleagues…”, “I managed a team of 6 developers …”) and hard skills (“… we created an application used by 1 mil people”, “… I helped optimize rendering time of the application”, “… created dozens automated tests”).

What’s the main selling point of React to you. Why did you chose to go with React?

I don’t expect you to mention JSX, VDOM etc. — we already get that from reading the “features” blurb on the homepage. Why did *you* start using React?

Was it because of the “easy to learn, hard to master” API (which is quite small when you compare it to other solutions)? Good — say that, it means you’re willing to learn new things, and learn them as you go.

Was it because of the “job opportunities”? Good — you’re a person that can adapt to the market and will have no issues moving on in 5 years when The Next Big Framework comes. We have enough of jQuery developers already.

Think of this a bit like an “elevator pitch” scenario (you are in an elevator with your boss and need to convince him to use new technology before they get out on his 20th floor). I wan’t to know you know what React has to offer that can benefit the client and you, the developer.

Let’s start to get a bit more technical

As I mentioned in one of the opening paragraphs — I’m not going to ask you what VDOM is. We know it, I will however ask you …

What is JSX and how come we can write it in our JavaScript code — how do the browser recognize it?

You know this — JSX is just a notation, that Facebook popularized, which — thanks to tools like Babel / TSC — allows us to write React.createElement calls in a form that’s a bit more pleasant to the eye.

Why do I ask this question? I want to know if you understand the technical side of JSX and all the limitations that come from it: why do we need to import React from 'react' on the top of the file even if we don’t use React in our code; why can’t the component directly return multiple elements.

Bonus question: why do the Component names in JSX start with capital letter?
Answering that this is how React knows to render a Component, and not a HTML Element should be good enough.

Bonus points: there are exceptions to that rule. E.g. assigning a component to this.component and then doing <this.component /> will work.

What are the main 2 types of components you can declare in React, and when would you use one over another.

Some people will think this is about presentation and container components, but this is more about React.Component and function components.

A proper answer should mention life cycle methods and component state.

Since we mentioned life cycle — can you walk me through the cycle of mounting a stateful component? What functions are called in what order? Where would you place a request for data from the API? Why?

Ok, that’s a long one. Feel free to break it into two smaller ones. You’re now thinking “but you said you don’t ask about life cycle!”. I don’t, I don’t care about the life cycle. I care about the changes that happened in the life cycle in the very recent months.

If the answer contains componentWillMount you can assume that the person has been either working with an older version of React exclusively, or has done some outdated tutorials. Both cases should rise some concerns. getDerivedStateFromProps is what you’re looking for.

Bonus points: differences in the way the process goes on server-side is mentioned.

Same goes for the question about data fetching — componentDidMount is the one you want to say/hear.

Bonus question: why componentDidMount and not constructor?
Two reasons you want to hear are: “the data will not be there before render happens” — although not the main reason, it shows you that the person understands the way components are handled; “with the new asynchronous rendering in React Fiber …” — someone has been doing his homework.

We mentioned fetching data from an API — how would you go about making sure the data is not re-fetched when the component is re-mounted?

We assume “cache invalidation” is not a thing. This one is not strictly React related, but if the answer is limited to React it’s also good — maybe they’ve worked with GraphQL which does the heavy lifting for you?

I ask this to see if the candidate understands the idea of not-coupling the UI and other layers in an application. An API that’s external to the React structure can be mentioned.

Can you explain the idea of “lifting the state up”?

Ok, I do ask some typical React questions. This one is crucial though, it will allow you to give the candidate some breathing room.

Answers ranging from “it allows to pass data between siblings” to “it allows you to have more pure-presentational components, which make re-usability easier” are preferred. Redux might get mentioned here, though that could as well be a bad thing, because it signifies that the candidate just goes with whatever the community recommends without understanding why they needs it.

Bonus question: how would you go about passing data across multiple levels of depth, without passing it from component to component?
Context has become mainstream ever since React 16.3 — it was there before, but the documentation was lacking (on purpose). Being able to explain how context works (and at the same time showing knowledge of the function-as-child pattern) is a plus.

If Redux / MobX gets a mention here, it’s also good.

React ecosystem

Developing React apps is part of the process — there’s a lot more to it: debugging, testing, documenting.

How would you go about debugging an issue in React code; what tools have you used? How would you go about investigating why a component does not re-render?

Everyone should be familiar with the basic tools like a linter (eslint, jslint) and debuggers (React Developer Tools).

Using RDT to debug the issue by checking if the component state/props are properly set is a good answer, mentioning using the Developer Tools to setup breakpoints is also a good one.

What testing tools have you used to write unit / E2E tests? What’s snapshot testing and what are the benefits of it?

In most cases tests are a “necessary evil” but those are things we need. There are many good answers here: karma, mocha, jasmin, jest, cypres, selenium, enzyme, react-test-library etc. The worst thing is the candidate answers “we didn’t do unit tests at my previous company, only manual tests”.

The snapshot testing part also depends on what you use in your project; if you don’t find it beneficial, don’t ask about it. But if you do, fast and easy regression tests for the UI layer (generated HTML + CSS).

Small code challenges

When possible, I also do small code challenges which should take no more than a minute or two to fix/explain, e.g.:

/** * What is wrong with this example, and how would you go  
* about fixing or improving the component? 
*/ 

class App extends React.Component {  
  constructor(props) {
    super(props);
    this.state = {
      name: this.props.name || 'Anonymous'
    }
  }    

  render() {
    return (
      <p>Hello {this.state.name}</p>
    );  
  }
}

There are multiple ways to solve it: remove the state and use props, implement getDerivedStateFromProps or (preferably) change to a function components.

/**
 * Can you explain the differences between all those ways
 * of passing function to a component?
 *
 * What happens when you click each of the buttons?
 */

class App extends React.Component {
  
  constructor() {
    super(); 
    this.name = 'MyComponent';
    
    this.handleClick2 = this.handleClick1.bind(this);
  }
  
  handleClick1() {
    alert(this.name);
  }
  
  handleClick3 = () => alert(this.name);

render() {
    return (
      <div>
        <button onClick={this.handleClick1()}>click 1</button>
        <button onClick={this.handleClick1}>click 2</button>
        <button onClick={this.handleClick2}>click 3</button>
        <button onClick={this.handleClick3}>click 4</button>
      </div>
    );
  }
}

This one takes a bit more, because there’s just more code. If the candidate answers correctly follow up with “why?”. Why will click 2 work the way it works?

Not a React question, if someone starts with “because in React …” it means that they don’t really understand the JS event loop.

/**
 * What's the issue with this component. Why?
 * How would you go about fixing it?
 */

class App extends React.Component {

state = { search: '' }

handleChange = event => {

/**
     * This is a simple implementation of a "debounce" function,
     * which will queue an expression to be called in 250ms and
     * cancel any pending queued expressions. This way we can 
     * delay the call 250ms after the user has stoped typing.
     */
    clearTimeout(this.timeout);
    this.timeout = setTimeout(() => {
      this.setState({
        search: event.target.value
      })
    }, 250);
  }

render() {
    return (
      <div>
        <input type="text" onChange={this.handleChange} />
        {this.state.search ? <p>Search for: {this.state.search}</p> : null}
      </div>
    )
  }
}

OK, this one will need some explaining. There’s no error in the debounce function. The way the application is expected to work, is it will update the state 250 ms after the user has stooped typing, and then render the string “Search for: …”.

The issue here is that the event is a SyntheticEvent in React, and if the interaction with it is delayed (e.g. via setTimeout) it will be cleared and the .target.value reference will no longer be valid.

Bonus points: the candidate is able to explain why that is.

We’re done with the tech questions.

This should be enough to give you some idea about the technical skills of the candidate. You should still have some time left for more open-ended questions.

What was the biggest problem you’ve faced on your past projects; what was your biggest achievement?

This goes back to the very first question — the answer can vary from developer to developer and position to position. A junior developer will say his biggest problem was getting thrown in a complex process, but they were able to conquer it. Someone looking for a more senior position will explain how they optimized the app performance, and someone that can lead teams explain how they’ve improved velocity by doing pair programming.

If you had unlimited time budget and could fix / improve / change one thing in your last project, what would it be and why?

And another open ended question, answer to which depends on what you’re looking for in the candidate. Will they try to replace Redux with MobX? Improve the testing setup? Write better documentation?

Reversing the tables and feedback

Now’s the time to change the roles. You probably have a solid idea about the candidate skills and potential to grow. Let him ask the questions — not only will it allow him to get to know the company and product more, the questions theyask might give you some indication about the direction they want’s to grow in.

Carl Vitullo wrote some good articles on the topic of what questions to ask your potential employer, I’ll refer you to those — be ready to answer them, or say that you can’t on given step due to NDA requirements etc.:

• onboarding and the workplace
• development and emergencies
• growth

Give feedback

If the candidate under-performed on some questions or got them wrong (or different than you would expect) — you might want to clarify those at this point. Don’t make it sound like you’re patronizing the person, just explain the problems you’ve noticed — offer solution and some resources they can use to improve.

If the rest of the recruitment process is up to you, tell them you will get back o them in X days, if not, tell them that someone from your company will do that. If you know the process will take longer than 2–3 days, tell them that. IT is a big market at this point, and the candidate might have done multiple interviews — they might not wait for you to get back before accepting another offer.

Do not ignore the candidate — that’s literally the main complaint people share on social media.

The opinions expressed in this blog post are those of my own and do not reflect the opinions of any of my past or current employer, client or collaborator.

The topic of security on the frontend part can be separated into two purposes:

• keeping your client and their data secure
• keeping your clients away from things they should not have access to

The first part is a very vast topic that covers things like cross-site-scripting (XSS), cross-site-request-forgery (CSRF), CORS and other topics related to how browser keep your data from leaking out to attacker or preventing attacker from performing actions in your name.

The second part is more concerned with “how do I limit my users from accessing certain parts of my site” — things like members only section, admin panel etc.

Are variables in browser secure?

Your first idea might be “I’m going to create an isAdmin variable, set it to true whenever an admin authenticates and then check it in my application.

But once you implemented that solution — a question hits you — “What if the user just opens developer tools and changes it to true on his end? How can I prevent that? Should I use localStorage, sessionStorage or is there something more secure?”

We need to make one thing clear — everything you put in the client browser can be easily changed by the client. The browser — by default — gives an attacker all the tools he needs. He can open the devtools and change all the in-memory variables. He can manipulate localStorage, sessionStorage, cookies and with the correct extensions even React components state. He can also substitute the response of the auth endopint and just make it response with {isAdmin: true} every time.

You might think that you could use some form of encoding — either roll out your own, or use JWT which you can then verify in the browser for any modifications. This approach is also flawed, because you would need to make the browser aware of the mechanism (keys) used to generate the signature — else the attacker would just need to make up his own keys, change the isAdmin field in the JWT and sign it with his key — the signature is valid, the browser accepts the JWT as legit and trusts that the user is an admin.

How do I prevent the user from accessing non-public parts of my site?

You do it exactly as you though to do it — you create a variable, set it to true for admins only and once the check passes, show the admin only content.

“Ok, that’s not secure at all — everyone can then go to the admin page and delete everything!” you scream.

Fair — but only if you implement your application in a bad way. The frontend part should not be concerned with the validity or not of credentials provided. It should always accept the data as “true” and just render all the data it is passed.

It it’s the backend job to perform this validation!

Your UI can have a “Delete database” button. You might even try to hide it with some logic, but an attacker can download the JavaScript code and look for all endpoints — he will find http://example.com/api/database/delete URL (this is only for the sake of the example, you should always use CRUD notation anyway :)) and call it manually. If this operation ends up in deleting your database — you seriously need to add more security to your application.

In similar vein, your application can render members only content under /members/blogpost/read-up-on-all-the-new-things — the attacker can always navigate to it directly. If he were to see the content, that means your API (or other forms of content delivery) is not designed correctly — the attacker should be then redirected to /sign-up right away, or in the worst case he should see an blog post template without any content loaded.

Backend is the deciding factor

In both cases above, the attacker is able to get into gated-off content, but he is unable to perform the operation associated with the action. All of them should communicate with the backend and contain some form of authentication (am I who I say I am) and authorization (can I perform this action) mechanisms.

If the action is permitted, perform it and reply with a proper HTTP code (e.g. 200), if it’s not permitted, reply with an HTTP error code — e.g. 401 (not authenticated) or 403 (not authorized). Your frontend should respond to this and either let the user know he’s doing something he has no authorization to (show an error message, redirect to a login screen) or just fail gracefully (render an template with no content or *gasp!* — Published at: <date>undefined</date>).

Before the advent of applications fully generated by JS, in the browser, HTML was returned in response to the HTTP call — be it by returning a static HTML content file, or by processing the response via server side languages (such as PHP, Python or Java) and responding in a more dynamic way.

A solution like this allows us to deliver responsive sites that work a lot faster than standard request-response model by removing the “request travel time”.

A typical response sent by the server when requesting a React site will look something like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <link rel="shortcut icon" href="/favicon.ico">
    <title>React App</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/app.js"></script>
  </body>
</html>

After fetching this response our browser will also fetch the app.js “bundle” which contains our application and after a second or two render the complete page.

At this moment we can use our browser HTML Inspector to view the complete rendered HTML, but when we view the actual source we will see nothing more than the above HTML code.

Why is this an issue?

While this behavior will not be a problem for most our users or when developing the application it will become an issue if:

• the end user is using a slow internet connection, especially mobile connection,
• the end user is running an underpowered device, for example an older generation mobile device,

If your target demographic falls into one of those groups they will have a bad experience using the site — for example will have to wait a lot longer, staring at the “Loading …” (or even worse — a blank screen) message.

“OK, but my target demographic is not in any of those groups, should I still care?”

There’s one more important thing you should consider when going with a client-side rendered app: search engines and social networks presence.

Currently, of all the search engines only Google has limited capabilities to render and JS site before indexing it. In addition, while Google will be able to render the index page of your website it is known to have issues navigating around sites with a router implementation.

This means that your site will have very hard time trying to get top position in the search results in anything but Google.

The same issue is visible in social platforms such as Facebook — when sharing a link to your site neither the title nor the thumbnail will render properly.

How to solve the issue

There are a few ways we can solve the issue.

A — Consider having your key pages as static

When you’re creating an platform that requires the users to login, and not providing the content to not-signed in users you might decide to create your public facing sites (like the index, “about us”, “contact us” etc.) pages as static HTML, and not have them rendered by JS.

Since your content is gated by login requirements it will not be indexed by search engines or shared in social media.

B — Generate parts of your application as HTML pages when running the build process

Libraries like react-snapshot can be added to your project, used to generate HTML copies of your application pages and save them to a specified folder. You can then deploy this folder alongside your JS bundle. This way, the HTML will be served along with the response allowing your site to be accessible by users with JavaScript disabled, search engines etc.

In most cases, configuration of react-snapshot is as simple as adding the library to your project, and altering the build script by calling it at the end:

"build": "webpack && react-snapshot --build-dir static"

The downside of this solution is that all the content we want to generate must be available at build time — we can’t query any APIs to get it, we can’t pre-generate content that depends on user provided data (e.g. as URL).

C — Create a server-side rendered application in JS

One of the big selling point of the current generation of JS applications is the fact, that they can be ran on both the client (browser) and on server — this allows us to generate HTML for pages that are more dynamic — which content is not known at build time. This is often referred to as “isomorphic” or “universal” application.

Two of the most popular solutions that provide SSR for React are:

• next.js — https://github.com/zeit/next.js/
• Gatsby — https://github.com/gatsbyjs/gatsby

Create your own custom SSR implementation

Important: If you’re willing to try to and create your own SSR implementation for your React applications, you’re going to need to be able to run a node backend for your server. You will not be able to deploy this solution to static host like github pages.

First step we’re going to take is to create an application just like you would with any other React application.

Let’s create our entry point:

// index.js
import React from 'react';
import { render } from 'react-dom';
import App from './App.js';

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

And the App component:

// App.js
import React from 'react';

const App = () => {
  return (
    <div>
      Welcome to SSR powered React application!
    </div>
  );
}

And our “shell” to load our application:

// index.html
<!doctype html>
<html>
  <head>
    <meta charset="utf-8" />
  </head>
  <body>
    <div id="root"></div>
    <script src="/bundle.js"></script>
  </body>
</html>

As you see our application is quite simple. We’re not going to go through all the steps needed to generate the proper webpack+babel setup in this article.

If you run the application in its current state, you will notice the welcome message on screen, and viewing the source you will see the content of index.html file, without the actual welcome message. To solve this issue let’s add server side rendering. First, we will need to add 3packages:

yarn add express pug babel-node --save-dev

Express is a powerful webserver for node, pug is a templating engine we can use with express, and babel-node is a wrapper for node, which allows it to perform code transpilation on the fly.

First, we will make a copy of our index.html file, and save it as index.pug:

// index.pug
<!doctype html>
<html>
  <head>
    <meta charset="utf-8" />
  </head>
  <body>
    <div id="root">!{app}</div>
    <script src="bundle.js"></script>
  </body>
</html>

You’ll notice the file is basically the same, save for !{app} being inserted into the HTML. This is a pug variable, which will be later on replaced by the actual HTML.

Let’s now create our server:

// server.js

import React from 'react';
import { renderToString } from 'react-dom/server';
import express from 'express';
import path from 'path';

import App from './src/App';

const app = express();
app.set('view engine', 'pug');
app.use('/', express.static(path.join(__dirname, 'dist')));

app.get('*', (req, res) => {
  const html = renderToString(
    <App />
  );

  res.render(path.join(__dirname, 'src/index.pug'), {
    app: html
  });
});

app.listen(3000, () => console.log('listening on port 3000'));

Let’s step through the file.

import { renderToString } from 'react-dom/server';

react-dom library contains a separate, named export renderToString which works similarly to the render we know, but instead of rendering to the DOM, it renders the HTML as string.

const app = express();
app.set('view engine', 'pug');
app.use('/', express.static(path.join(__dirname, 'dist')));

We’re creating a new express server instance, and letting it know we want to use the pug template engine. We could get away with reading the file and doing a search & replace, but that’s really ineffective and can cause issues with multiple access to the file system or caching issues.

In the last line, we’re instructing express to look for file in the dist folder, and if a request (e.g. /bundle.js) matches a file, that is present in that folder, reply with it.

app.get('*', (req, res) => {
});

Now in turn we ask express to add a handler for any unmatched URL — this includes our non-existing index.html file (remember, we renamed it to index.pug and also it’s not available in the dist folder).

const html = renderToString(
  <App />
);

Using renderToString we render our application. This code looks exactly like our entry point, but it does not have to.

res.render(path.join(__dirname, 'src/index.pug'), {
  app: html
});

Once we have the rendered HTML, we tell express to respond by rendering the index.pug file, and replacing the app variable, with the HTML we received.

app.listen(3000, () => console.log('listening on port 3000'));

Last part is actually starting the server, and making it listen on port 3000.

All that’s left to do is to add a proper script topackage.json:

"scripts": {
  "server": "babel-node server.js"
}

Now, once we call yarn run server we should receive a confirmation, that the server is indeed running. Navigate your browser to http://localhost:3000 where you should again see your application. But this time if you view the source you should see:

<!doctype html>
<html>
  <head>
    <meta charset="utf-8" />
  </head>
  <body>
    <div id="root">div data-reactroot="">Welcome to SSR powered React application!</div></div>
    <script src="bundle.js"></script>
  </body>
</html>

If that is the case, it means that server-side rendering is working as expected, and you can start to grow your application!

Why do we still need bundle.js?

In case of our super-simple application, inclusion of bundle.js is not needed — without it, our application would still work. But in case of real-life applications, you’d still want to include the file.

This allows the browsers that know how to handle JavaScript to take over and perform the future interaction with your page on the client side, and those that do not know how to parse JS to navigate the page with the actual HTML returned by the server.

Things to keep in mind

While SSR might look simple enough, when developing the application you need to watch out for some topics, which might not be initially clear:

• any state generated on the server side will not be passed to the client application state; that means that if your backend fetches some data and uses it to render HTML, it will not be placed in the this.state that the browser sees
• componentDidMount is not called on the server — this means that none of your data-fetching that you’re used to place there will not be called; this is generally a good thing, as you should be providing the data as props if you need it. Remember that you need to delay your render (calling res.render) until the data is fetched, which might introduce some delay for your visitors
• if you’re using a react router (e.g. @reach/router or react-router) you need to make sure that the proper URL is passed to the application when it’s rendered on the server — be sure to check the proper documentation!

This article is an update on the previous one, which talked about the “old” lifecycle, thus it’s not going to focus on all of the lifecycles, only the new ones.

static getDerivedStateFromProps(nextProps, prevState)

The new function which main responsibility is ensuring that the state and props are in sync for when it is required. It’s main job is replacing componentWillReceiveProps

gDSFP is a static function and as such has no access to this — you are instead expected to return an object, which will be merged into the future state of the component (exactly like working with setState!)

The function is used when a component is updated but also when it is mounted, right after the constructor was called, so you no longer need to use constructor or class property form of state if you want to set initial state from props.

getSnapshotBeforeUpdate(prevProps, prevState)

Other of the two new functions, invoked in the so called “pre-commit phase”, right before the changes from VDOM are to be reflected in the DOM.

It is usable mostly if you need to read the current DOM state, for example you have an application in which new messages are added to the top of the screen — if a user scrolled down, and a new message is added the screen could move and make the UI harder to use. By adding getSnapshotBeforeUpdate you can calculate current scroll position and maintain it through the DOM update.

Even though the function is not static, it is recommended to return the value, not update the component. The returned value will be passed to componentDidUpdate as the 3rd parameter.

Deprecated functions

While the new functions are there to make your transition to AsyncMode easier, you are not forced to migrate all your code. The following functions will be marked as deprecated and in later releases renamed:

• componentWillReceiveProps — UNSAFE_componentWillReceiveProps
• componentWillUpdate — UNSAFE_componentWillUpdate

You will start seeing the deprecation warnings in next major version, and the function will be removed (the renamed versions will be kept!) in version 17.0

Dan Abramov summarized the whole change in one image for your pleasure:

In short: the new feature allows you to defer rendering part of your application tree until some condition is met (for example data from an endpoint or a resource is loaded).

Why do we need this?

Delaying displaying content is possible already, all one has to do is check if the data is loaded, and if not, show a spinner — if it’s as simple as that why do we need this?

In reality things are a bit more complicated than that:

• with this approach we need to either implement the loading screen in the component which requests / consumes the data, or expose its API to parent
• things get more complicated the more content we need to load (what if you wanted to load a movie details page only when the reviews and all images are also already loaded?)
• once we start making use of AsyncMode things will get even more complex — parts of your application might have new data, parts of it old, which would lead to “tearing” or “flickering” of content

In order to fix those, and probably more issues which will become more apparent once AsyncMode becomes mainstream React team proposed the new API.

Another big issue that this solution aims to address is the user experience difference between users with fast device/network and slow ones. If we do go with the spinner that was our initial idea, we might end up showing it for a fraction of a second for users that have fast connection, in which case not showing it at all would be better UX as it eliminates screen flickering.

Live demo

I’ve been able to create a simple demo of the feature (with help from Dan and Aweary over at Twitter) so before we jump into the code you might want to check it out.

Disclaimer

Please note that the current API is not final and will more than likely change before public release.

Let’s step through the code

Most of the code should be easy to follow (remember to also check the comments :)) but there are some things created just for Dan’s demo or introduced in the alpha of React.

Resource fetcher / cache provider / “abstractor of the API”:

The two functions you see here are provided by simple-cache-provider package created by Andrew. Here’s what exactly it’s doing:

1. create a shared cache object
2. create a “resource fetcher” (createResource) which you call with a set of parameters
3. return a promise that will resolve after a set time, with the input value

This is a really simple example, which in a real-world app would probably be replaced by an API call or similar mechanism. The most important part is that the readText function which once called, will either directly return the value it resolves to (not the Promise!) or would throw a Promise.

Wait — what?

Yes, you read that right, the function either returns the value, or throws — so you can do:

The call to readText will either resolve to the Promise value or will end up throwing the Promise.

Since this is not apparent (it’s hidden inside simple-cache-provider), you can imagine another version of the AsyncText component:

As we know, a React Component can only return JSX (or null) — so we need a method of communicating that we’re “not yet ready” to any parent that is prepared to handle that status. Sounds a bit familiar? If it does, that’s because React already has a mechanism that allows you to throw in a component and let its parent or grand-parent handle this — Error Boundaries. Suspense is reusing some of this API for its own purposes.

Using the component

If we were to use the component right away, React would warn us that we’re “doing it wrong”:

In order to properly render the component, we need to import a new React primitive component and create a helper for it:

We’re using the new Timeout component which accepts two input props:

• ms prop, which indicates the time after which we want to see the fallback content (here passed to the Loader component as prop!)
• children which should be a “function as a child” or “render prop” function; this function will be called with one parameter, which indicates if the specified time elapsed

Let’s take a dive into what’s actually going on there. When this component gets rendered, React will call the child function right away with a value of false which will allow us to render the child component.

Once the child component renders, it will try to read the data, find out that it’s not there and throw the promise. At this point React catches the Promise, waits the correct time (provided as ms prop) and runs the function again, this time with true so that we can show the fallback.

Once the Promise resolves, the function is called yet another time, again with false which end up rendering the correct component.

We could go without creating this helper and inline it all in our component, but this makes it more reusable and easier to read when actually …

Using the components

Putting the components together gets rid of the error from previous sections and allows us to have a placeholder shown while the data is being “fetched”. There’s only one issue though — if we were to simply use setState to toggle the visibility of our component (or render it right away) the placeholder would be shown right away — not after the specified time.

Here we get to the last part of the puzzle:

ReactDOM.unstable_deferredUpdates is a callback which was introduced back in initial React Fiber release (so 16.0) which allows you to schedule an update with low priority. This is the part that actually allows the Timeout component to “wait” before re-rendering itself.

What to expect?

A week before Dan’s talk, Andrew Tweeted the following:

Was he right? I think it was. This addition to React tool-set helps us solve a lot of problems we are facing today such as:

• data fetching, without locking the UI and at the same time allowing users to change their decision while data is being fetched (which could result in race conditions)
• providing good experience to users with low-end, high-latency devices
• creating a common abstraction over “loading” state

Once the API gets finalized, we will probably see a lot of libraries pioneering the solution and will have to adjust our best practices (suddenly calling AJAX requests inside render will become OK) but I believe this will allow us all to create even better applications and experience for users!

Please note that the current API is not final and will more than likely change before public release.

Update 05.02.2018 — I’ve previously made some wrong observation about the createContext behavior, this section was updated to reflect the actual behavior of the factory function.

New context API

Context API was always a thing of mystery — it’s an official, documented React API but at the same time developers warned us not to use it because the API might change with time, and it was missing some documentation on purpose. Well, that time is now — the RFC phase has passed and the new API is merged. It is definitely more “user friendly” and might make your life a bit easier when all you want is simple state management without the “overhead” of Redux or MobX.

The new API is accessible as React.createContext() and creates two components for us:

Calling the factory function will return us an object that has a “Provider” and a “Consumer” in it.

The “Provider” is a special component which aims to provide data to all components in its sub-tree, so one example of usage would be:

Here we select a sub-tree (in this case, the whole tree) to which we want to pass our “theme” context, and set the value we want to pass. The value can of course be dynamic (e.g. based on this.state).

Next step is to use the Consumer:

If you happen to render the “Consumer” without embeding it in a corresponding “Provider”, the default value declared at createContext call will be used.

Please notice some things:

• the consumer must have access to the same Context component — if you were to create a new context, with the same parameter as input, a new Context would be created and the data would not be passed. For this reason please consider Context a component — it should be created once and then exported + imported whenever needed
• the new syntax uses the function as child (sometime called render prop) pattern — if you’re not familiar with this pattern I recommend reading some articles on it
• it is no longer required to use prop-types to specify contextProps if you want to make use of the new Context API

The data from the context passed to the function matches the value prop set in the providers Context.Provider component, and altering the data in the Provider will cause all consumers to re-render.

New life-cycle methods

The other RFC to make it into the alpha release concerns deprecation of some life-cycle methods and introduction of one (four) new.

This change aims to enforce best practices (you can read up on why those functions can be tricky in my article on life-cycle methods) which will be very crucial once the asynchronous rendering mode (which was one of React 16 “Fiber” main goals) will be fully activated.

The functions that will be in time considered deprecation are:

• componentWillMount — please use componentDidMount instead
• componentWillUpdate — please use componentDidUpdate instead
• componentWillReceiveProps — a new function, static getDerivedStateFromProps is introduced

Do not be alarmed, you are still able to use those functions — the depracation notices are slotted for 16.4 and removal of them is planned in 17.0

You will only see the deprecation notices if you also opt in into the new StrictMode or AsyncMode in which case you can still suppress them by using:

• UNSAFE_componentWillMount
• UNSAFE_componentWillReceiveProps
• UNSAFE_componentWillUpdate

static getDerivedStateFromProps

As componentWillReceiveProps gets removed, we need some means of updating the state based on props change — the community decided to introduce a new — static — method to handle this.

What’s a static method? A static method is a method / function that exists on the class not its instance. The easiest difference to think about is that static method does not have access to this and has the keyword static in front of it.

Ok, but if the function has no access to this how are we to call this.setState? The answer is — we don’t. Instead the function should return the updated state data, or null if no update is needed:

The returned value behaves similarly to current setState value — you only need to return the part of state that changes, all other values will be preserved.

Things to keep in mind:

You still need to declare the initial state of the component (either in constructor or as a class field).

getDerivedStateFromProps is called both on initial mounting and on re-rendering of the component, so you can use it instead of creating state based on props in constructor.

If you declare both getDerivedStateFromProps and componentWillReceiveProps only getDerivedStateFromProps will be called, and you will see a warning in the console.

Usually, you would use a callback to make sure some code is called when the state was actually updated — in this case, please use componentDidUpdate instead.

If you prefer not to use the static keyword, you can use the alternative syntax:

StrictMode

Strict mode is a new way to make sure your code is following the best practices. It’s a component available under React.StrictMode and can be added to your application tree or subtree:

If one of the children components, rendered in the StrictMode subtree uses some of the method mentioned in previous paragraphs (like componentWillMount) you will then see an error message in browser console when running an development build:

Currently the error message points to the RFC for the life-cycle methods removal.

AsyncMode

The not-yet-active async Component support was renamed to be aligned with the StrictMode and is now available under React.unstable_AsyncMode. Using it will also activate StrictMode warnings.

If you want to learn more about asynchronous components you might check some articles / examples at:

• https://build-mbfootjxoo.now.sh/
• https://github.com/koba04/react-fiber-resources

New version of React Developer Tools

Additionally, a new version of the Developer Tools was released to support debugging the new components.

If you’re using Chrome — you might need to wait a bit more, as it’s not updated yet in the store, and trying to debug results in … interesting results:

Firefox users should be able to make use of the new features already:

More to come?

Please keep in mind that this is an alpha release and the stable 16.3 might have more / fewer changes. That said, according to Dan, 16.3 should be released “sometime next week”:

If you ever worked with an AJAX call, you are probably familiar with the following error displayed in browser console:

If you see this message it means the response failed yet you are still able to see the returned data if you go to the Network tab — what’s the idea here?

Cross-Origin Resource Sharing (CORS)

The behavior you are observing is the effect of browsers CORS implementation.

Before CORS became standarized there was no way to call an API endpoint under different domain for security reasons. This was (and to some degree still is) blocked by the Same-Origin Policy.

CORS is a mechanism which aims to allow requests made on behalf of you and at the same time block some requests made by rogue JS and is triggered whenever you are making an HTTP request to:

• a different domain (eg. site at example.com calls api.com)
• a different sub domain (eg. site at example.com calls api.example.com)
• a different port (eg. site at example.com calls example.com:3001)
• a different protocol (eg. site at https://example.com calls http://example.com)

This mechanism prevents attackers that plant scripts on various websites (eg. in ads displayed via Google Ads) to make an AJAX call to www.yourbank.com and in case you were logged in making a transaction using *your* credentials.

If the server does not respond with specific headers to a “simple” GET or POST request — it will still be send, the data still received but the browser will not allow JavaScript to access the response.

If your browser tries to make a “non simple” request (eg. an request that includes cookies, or which Content-type is other than application/x-ww-form-urlencoded, multipart/form-data or text-plain) an mechanism called preflight will be used and an OPTIONS request will be sent to the server.

An common example of “non simple” request is to add cookies or custom headers — it your browser sends such a request and the server does not respond properly, only the preflight call will be made (without the extra headers) but the actual HTTP request the brower meant to make will not be sent.

Access-Control-Allow-What?

CORS uses a few HTTP headers — both in request and response — but the ones you must understand in order to be able to continue working are:

Access-Control-Allow-Origin

This header is meant to be returned by the server, and indicate what client-domains are allowed to access its resources. The value can be:

• * — allow any domain
• a fully qualified domain name (eg. https://example.com)

If you require the client to pass authentication headers (e.g. cookies) the value can not be * — it must be a fully qualified domain!

Access-Control-Allow-Credentials

This header is only required to be present in the response if your server supports authentication via cookies. The only valid value for this case is true.

Access-Control-Allow-Headers

Provides a comma separated list of request header values the server is willing to support. If you use custom headers (eg. x-authentication-token you need to return it in this ACA header response to OPTIONS call, otherwise the request will be blocked.

Access-Control-Expose-Headers

Similarly, this response should contain a list of headers that will be present in the actual response to the call and should be made available to the client. All other headers will be restricted.

Access-Control-Allow-Methods

A comma separated list of HTTP request type verbs (eg. GET, POST) which the server is willing to support.

Origin

This header is part of the request that the client is making, and will contain the domain from which the application is started. For security reasons browsers will not allow you to overwrite this value.

How to fix the CORS “error”?

You have to understand that the CORS behavior is not an error — it’s a mechanism that’s working as expected in order to protect your users, you, or the site you’re calling.

Sometimes the lack of proper headers is result of wrong client-side implementation (eg. missing authorization data such as API key).

There are a few ways to “fix the error” depending on the scenario you’re facing:

A — I’m developing the frontend and have control of or know the person developing the backend

This is the best case scenario — you should be able to implement the proper CORS response on the server which you’re calling. If the API is using express for node you can use the simple cors package. If you want to make your site properly secure, consider using a whitelist for the Access-Control-Allow-Origin header.

B — I’m developing the frontend but have no control of the backend now, I need a temporary solution

This is the second-best scenario, because it’s just the A one, but with some time constrains. To temporary fix the issue you can make your browser ignore CORS mechanism — for example use the ACAO Chrome extension or by disabling it completely by running Chrome with the following flags:

chrome --disable-web-security --user-data-dir

IMPORTANT please remember that this will disable the mechanism for every website for the duration of your whole browser session. Use with caution.

Another alternative here is using devServer.proxy (assuming you’re using webpack to serve your app) or use a CORS-as-a-service solution such as https://cors-anywhere.herokuapp.com/

C — I’m developing the frontend, have no control of the backend and never will

Ok, now things are getting complicated. First you should probably establish why the server is not sending the proper headers.

Maybe they do not allow 3rd party apps to access their API? Maybe their API is only meant to be consumed by server-side applications and not browsers? Maybe you should be sending an authorization token of sorts in the URL?

If you still think you should be able to access the data via browser, you will have to write your own proxy that will sit between the browser application and the API, similarly to how we did it in solution B.

The proxy does not have to be running on the same domain as your application, as long as the proxy itself properly supports CORS when communicating with the client. The communication between proxy and the API does not have to support CORS at all.

You can either write your own platform, or use a ready made solution such as https://www.npmjs.com/package/cors-anywhere

Remember that such approach can introduce a security risk if you want to support credentials.

More about CORS

If you wish to learn more about CORS details I recommend checking out the detailed MDN article.

Update:

React 16.3 introduced two more life-cycle methods and depracated few of them, be sure to check up the follow-up at https://medium.com/@baphemot/understanding-react-react-16-3-component-life-cycle-23129bc7a705

constructor

constructors are the basic of OOP — this is a special function that will get called whenever a new object is created. It’s very important to call a special function super in cases where our class extends any other class that also has a defined constructor. Calling this special function will call the constructor of our parent class and allow it to initialize itself. This is why we have access to this.props only after we’ve initially called super.

As mentioned, constructors are perfect for setting up our Component — create any fields (variables starting with this.) or initialize state based on props received.

This is also the only place where you are expected to change / set the state by directly overwriting the this.state fields. In all other instances remember to use this.setState

DO

• set initial state
• if not using class properties syntax — prepare all class fields and bind functions that will be passed as callbacks

DON’T

• cause any side effects (AJAX calls etc.)

deprecated — componentWillMount

This is a somehow special case — componentWillMount does not differ much from constructor - it is also called once only in the initial mounting life-cycle. Historically there were some reasons to use componentWillMountover constructor see this react-redux issue but please keep in mind that the practice described there is since deprecated.

Many will be tempted to use this function in order to send a request to fetch data and expect the data to be available before the initial render is ready. This is not the case — while the request will be initialized before the render, it will not be able to finish before the render is called.

Additionally, with the changes to React Fiber (post React 16 beta release) this function might end up being called multiple times before the initial render is called so might result in triggering multiple side-effects. Due to this fact it is not recommended to use this function for any side-effect causing operations.

It is important to note that this function is called when using server-side-rendering while it counterpart — componentDidMount will not be called on the server but on the client in such case. So if some side-effect isdesired on the server part this function should be used as an exception.

A setState used in this function is “free” and will not trigger a re-render.

DO

• update state via this.setState
• perform last minute optimization
• cause side-effects (AJAX calls etc.) in case of server-side-rendering only

DON’T

• cause any side effects (AJAX calls etc.) on client side

deprecated — componentWillReceiveProps(nextProps)

This function will be called in each update life-cycle caused by changes to props (parent component re-rendering) and will be passed an object map of all the props passed, no matter if the prop value has changed or not since previous re-render phase.

This function is ideal if you have a component whose parts of state are depending on props passed from parent component as calling this.setState here will not cause an extra render call.

Please keep in mind that due to the fact that the function is called with all props, even those that did not change it is expected the developers implement a check to determine if the actual value has changed, for example:

componentWillReceiveProps(nextProps) {
  if(nextProps.myProp !== this.props.myProps) {
    // nextProps.myProp has a different value than our current prop
    // so we can perform some calculations based on the new value
  }
}

Due to the fact that with React Fiber (post 16 beta) this function might be called multiple times before the renderfunction is actually called it is not recommended to use any side-effect causing operations here.

DO

• sync state to props

DON’T

• cause any side effects (AJAX calls etc.)

shouldComponentUpdate(nextProps, nextState, nextContext)

By default, all class based Components will re-render themselves whenever the props they receiver, their state or context changes. If re-rendering the component is computation heavy (e.g. generating a chart) or is not recommended for some performance reasons, the developer is given access to a special function which will be called in the update cycle.

This function will be called internally with next values of props, state and object. Developer can use those to verify that the change requires a re-render or not and return false to prevent the re-rendering from happening. In other case, you are expected to return true.

DO

• use for increasing performance of poor performing Components

DON’T

• cause any side effects (AJAX calls etc.)
• call this.setState

deprecated — componentWillUpdate(nextProps, nextState)

If the shouldComponentUpdate function is not implemented, or it decided that the component should update in this render cycle, another life-cycle function will be called. This function is commonly used to perform state and props synchronization for when parts of your state are based on props.

In cases where shouldComponentUpdate is implemented, this function can be used instead of componentWillReceiveProps as it will be called only when the component will actually be re-rendered.

Similarly to all other componentWill* functions, this function might end up called multiple times before render so it it not advised to perform side-effects causing operations here.

DO

• synchronize state to props

DON’T

• cause any side effects (AJAX calls etc.)

componentDidUpdate(prevProps, prevState, prevContext)

This function will be called after render is finished in each of the re-render cycles. This means that you can be sure that the component and all its sub-components have properly rendered itself.

Due to the fact that this is the only function that is guaranteed to be called only once in each re-render cycle it is recommended to use this function for any side-effect causing operations. Similarly to componentWillUpdateand componentWillReceiveProps this function is called with object-maps of previous props, state and context, even if no actual change happened to those values. Because of that developers are expected to manually check if given value changed and only then perform various update operations:

componentDidUpdate(prevProps) {
  if(prevProps.myProps !== this.props.myProp) {
    // this.props.myProp has a different value
    // we can perform any operations that would 
    // need the new value and/or cause side-effects 
    // like AJAX calls with the new value - this.props.myProp
  }
}

DO

• cause side effects (AJAX calls etc.)

DON’T

• call this.setState as it will result in a re-render

An exception to the above rule is updating the state based on some DOM property which can be only computed once a component has re-rendered (e.g. position / dimensions of some DOM nodes). Please take extra care to prevent against updating if the value did not in fact change as it might result in a render loop.

componentDidCatch(errorString, errorInfo)

A new addition in React 16 — this life-cycle method is special in way that it can react to events happening in the child component, specifically to any uncaught errors happening in any of the child components.

With this addition you can make your parent-element handle the error by — for example — setting the error info in state and returning appropriate message in its render, or logging to reporting system, e.g.:

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

render() {
  if(this.state.error) return <ShowErrorMessage error={this.state.error} />
  return (
    // render normal component output
  );
}

When an error happens, the function will be called with:

• errorString — the .toString() message of the error
• errorInfo — an object with a single field componentStack which represent the stack trace back to where the error occured, e.g.:

in Thrower
    in div (created by App)
    in App

componentDidMount

This function will be called only once in the whole life-cycle of a given component and it being called signalizes that the component — and all its sub-components — rendered properly.

Since this function is guaranteed to be called only once it is a perfect candidate for performing any side-effect causing operations such as AJAX requests.

DO

• cause side effects (AJAX calls etc.)

DON’T

• call this.setState as it will result in a re-render

An exception to the above rule is updating the state based on some DOM property which can be only computed once a component has re-rendered (e.g. position / dimensions of some DOM nodes). Please take extra care to prevent against updating if the value did not in fact change as it might result in a render loop.

componentWillUnmount

Use this function to “clean up” after the component if it takes advantage of timers (setTimeout, setInterval), opens sockets or performs any operations we need to close / remove when no longer needed.

DO

• remove any timers or listeners created in lifespan of the component

DON’T

• call this.setState, start new listeners or timers

Component cycles

There are multiple reasons a component might re-render, and in each of them different functions are called allowing the developer to update certain parts of the Component.

Component creation

The first cycle is the creation for component, which usually happens the first time a component is encountered in the parsed JSX tree:

Component re-rendering due to re-rendering of the parent component

Component re-rendering due to internal change (e.g. a call to this.setState())

Component re-rendering due to call to this.forceUpdate

Component re-rendering due to catching an error

Introduced in React 16 as “ErrorBoundaries”. A component can define a special layer which can catch errors and provide a new life-cycle method — componentDidCatch - which allows developers to provide self-repair actions for recovery or graceful handling of errors.

Shoutout to @James_k_nelson, who just recently published a componentWillReceiveProps simulator, which you can find and play with at https://reactarmory.com/guides/lifecycle-simulators

Passing data to the application at run time is known as “initialization”, “bootstrapping” or “state hydration”. Lets go through couple of solutions.

Important:

Please note that allowing data from outside of your application to be accessed inside of React might open you to attacks such as XSS or CSRF. Please make sure all the data you are accessing in React comes from a trusted source.

While you do not need to use any special functions to escape characters, you should be very careful if you will be using dangerouslySetInnerHtml.

A — make a API call

The first solution assumes the data you are looking for is available by calling a API, which might be ideal when the response you expect will be the same for all of your users.

In order to get the data you can make an AJAX call (for example by using axios or fetch).

Pros:

• secure — very unlikely that an attacker would be able to inject malicious code

Cons:

• performs an additional HTTP request which adds to load time
• unless already authorized, can’t be used to fetch personalized response; authorization adds the overhead of yet another request

B — pass data via window object

When the data is already available to the backend (for example the user is already authorized, or set of images to display in your React widget is known) you can assign the data to window object and then read it in React application.

First lets make changes to our application:

class User extends React.Component {
  contructor() {
    super();
    if(window.reactApp) {
      this.state = { user: window.reactApp.user };
    }
    else this.state = { user: undefined };
  }
}

Now we can embed the application:

<div id="react"></div>
<script>
  window.reactApp = {
    user: {
      name: 'BTM',
      email: 'example@example.com'
    }
  }
</script>
<script src="react-application.js"></script>

Pros:

• data provided to React can be tailored to authorized user or generic on the backend side
• no additional requests needed

Cons:

• our application relies on the data provided from outside of React context, making it less reusable
• possibility of attackers manipulating the data via XSS/CSRF
• in case we want to embed multiple applications on the same page we would need to make each application use different window.reactApp variable if need to have different input data

C — pass data via attribute on parent node

This is basically a modified version of the example described above, but instead of storing the data in window global object, we are going to store it as a data-attribute on the node into which React will render.

This time let us start by changing the HTML:

<div id="react" data-react='{"user":{"name":"BTM","email":"example@example.com"}}'></div>
<script src="react-application.js"></script>

Now we can change our application:

const node = document.getElementById('root');
const userData = node.dataset.react ? JSON.parse(node.dataset.react) : {};
ReactDOM.render(<App user={userData.user} />, node);

Pros:

• data provided to React can be tailored to authorized user or generic on the backend side
• no additional requests needed
• we’re no longer polluting the window object

Cons:

• our application relies on the data provided from outside of React context, making it less reusable
• possibility of attackers manipulating the data via XSS/CSRF
• data needs to be provided as JSON string, which can lead to some issues in both security and data consistency

D — exposing the render function to HTML

The solutions provided before might very well be enough for most use case, but sometimes you want to be able to not only pass some data at run time but also be able to update it at later time or manually trigger the rendering of your application. In order to do just that we can provide our HTML page access to the rendering mechanism.

First thing we need to do is create a function that will init our application and expose it via window object (the function on itself would not be available outside of React context due to how Webpack works):

function runApplication(data, node) {
  ReactDOM.render(<App data={data} />, node);
}

window.runReactApplication = runApplication;

Now we can call our application at any given time:

<div id="MyApp"></div>
<script src="react-application.js"></script>
<script>
  window.runReactApplication({
    user: { name: 'BTM', email: 'example@example.com' }
  }, document.querySelector('#MyApp'));
</script>

Now, anytime we call the window.runReactApplication function with new data as first parameter (but the same node as the second one!) our <App /> component will receive new props, just like a normal React life-cycle would do it.

Pros:

• data provided to React can be tailored to authorized user or generic on the backend side
• no additional requests needed
• data can be updated and app rendered whenever it’s needed

Cons:

• app needs to be initialized from the HTML
• possibility of attackers manipulating the data via XSS/CSRF

Conclusion

As with all things React — there is no one, definitive answer to the question “how to pass initial data to my application” — you need to pick a solution that works best for your use case.

I will cover a couple of techniques and tools you will find useful when developing ReactJS applications. For the sake of this article I will be using Chrome browser, but most of the techniques are universal and the tools exist for different browsers as well.

Please keep in mind that some of the described scenarios assume you have source maps enabled in your build. While debugging an app without sourcemaps enabled is possible it is much harder.

Step 0 — get to know your browser

Most of the tools you need are already available to you, integrated with the browser — I’m talking about the browser’s developer tools. In most cases you can open them by pressing F12 or right clicking and selecting “Inspect”:

The two most important parts of the Devtools you should be familiar with will be “Console” and “Network”. I will cover those in further sections.

Code linting

While a linter might not help you debug your application it might prevent you from introducing the error in the first place. If you don’t want to spend time configuring and fine-tuning your ESLint (I recommend ESLint here as it’s one of the most popular and powerful) you can use the react-app preset.

Console — your first and most powerful friend

The console window is one of the most important tools at your disposal. Not only does it show all the messages your application is logging using console.log it also shows the majority of error messages in browser caused by your app. On top of that it’s an REPL environment into which you can type any valid JS code and have it executed right away.

console object in JS has a lot of features — if you want to read up on them I highly recommend the page over at MDN.

console is also your “basic” way to debug the application. Want to see if certain part of your code is reached? Is the onClick handler called? What’s the value of that variable? console.log it — in most cases the otput (or lack of it) will allow you to quickly assess what’s wrong with your application.

Keep in mind: console.log when used with an object/array as a parameter can be deceiving. Consider the following code:

const myObject = { name: 'BTM' }
console.log(myObject);
myObject.name = 'John';

What do you expect to see in the output of the log?

“Yes, ‘BTM’, just what I thought!” Is it?

Ok …. what’s going on here? console.log uses the reference when we expand it with the arrow down, but the value in the collapsed version. Keep that in mind when trying to debug React application — it might look like the valid data is passed to a child component while in fact it is being mutated in parent!

Network tab

There is a very high chance that your application uses some form of communication with a server, and ther ewill be times that you will get wrong data or data will come in a shape you weren’t expecting it. The Network tab is your “go to” here. It will track all HTTP and Websocket requests that happened since you opened the tool (this is sadly not true for Websockets — it will only show communication happening over sockets that were opened after you opened the Developer Tools, so if you need to spy on WS remember to have the tool opened beforehand):

Important things to keep in mind:

• a general rule-of-thumb is “red requests failed, white requests are OK”
• each request can have multiple states, keep an eye out on “Pending” requests — if the status persists for a longer time, it might mean you mistyped the URL or the backend is having troubles
• when you click on the request a detailed tab will open — “Preview” and “Response” tabs will show your data; if it looks like the data is OK but you can’t parse it in your app, check the “Content-type” in “Headers” tabs — sometimes servers will send you JSON data as text or HTML which can break some tools
• a very common error which results in data being visible in “Network” tab but not accessible to your app is failing the CORS protocol. Keep an eye out for errors like this in your “Console” section:

The CORS error is especially tricky as it will show as a successful request (it will be white on the list) and all the data you expect will be there in “Preview” tab. To get around CORS “limitation” you need to either work with the backend provider (in order to allow CORS on the server, or configure it in a way that it can be used by your app) or use a proxy solution (CORS affects only browsers — any proxy written in a server-side language will just ignore it).

React Developer Tools

A deceivingly small browser extension from Facebook will be your go-to tool when checking if the data and JSX structure is OK. You can either download the extension from the library for your browser or grab the standalone version.

After installing the extension you will notice an React icon on the iconbar that highlights whenever you visit an React powered site, and you will see another tab added to the browser Developer Tools. When opened you will see a view similar to HTML structure but instead of HTML nodes you will see the current JSX:

Clicking on each invidual JSX element will show you its important data: key, ref, its state and props. You can also use the tool to change some of the values (mostly scalar values: booleans, numbers, strings; it does not support changing objects on the fly).

You can use the “Search” box to look up your components by their name but another feature is the automatic lookup of an element you right clicked and selected “Inspect” on (all you have to do is change from “Elements” to “React” tab).

One of the most important features however lies in the update that React Developer Tools adds to the default “Console” window (if you don’t see it when on the “React” tab, click the three-dots icon and select “Show console drawer”). When an React element is selected you can use $r in the console which will give you this of the selected element:

You can interact with the element, call its methods and event handlers just like a normal interaction would. This feature allows you to change complex structures we mentioned earlier (e.g. you can select an element, call its $r.setState({message: 'Hello world!'}) which will trigger normal reconcilation process.

Important: if you’re running a production build, names of components will be obfuscated by default. You can get around that by setting a static variable displayName on the component. You can use babel-plugin-add-react-displayname to simplify the process.

Serious debugging — breakpoints

Now that we covered all the “easy” things let’s move into the “real world debugging” — working with breakpoints. A breakpoint is an instruction in code which will stop all the execution and fire up a debugger. There are 2 ways of setting up breakpoints that you will find handy:

• adding debugger; to your source code — when the parser encounters this directive, and the Developer Tools are open it will trigger a breakpoint
• finding the point on which we want to break in the Develooper Tools (“Sources” tab) and clicking on the line number — this will add a visual marker and will act exactly the same as above; breakpoints set up this way persist through browser refresh

When code execution reaches this point you will see that the page is in “paused” state and the Devtool now have some additional options:

The “Sources” panel shows on which breakpoint the code halted (you can have multiple breakpoints in your application at any given time) and the right hand side shows some interesting information about the current application state, most important are:

• the navigation panel on the top — allowing us to resume the application, step backwards / forwards in execution or disable all breakpoints
• the callstack — shows us what functions were called in order to get to the current application state
• scope — shows what variables are available at the current execution point in what scope (local, global, closure) along with their values; you can also change the values at this point, which — when resumed — will be reflected in your application
• the console is now hooked to the application state, you have access to all variables shown in “Scope” — this allows you to change values in code that is in other cases not accessible from window namespace (e.g. you get access to components this).

Specific tools

While the above described tools will come in handy in any JS / ReactJS application, there are some tools that you might find useful when working with specific issues / libraries, some of which are:

why did you update?

A small library that integrates with your components that shows you why a component did re-render; while the main goal is to provide ways to check for potential optimizations, it is generally useful when debugging rendering issues

redux-logger

Another small console addition, this time for when you are working with Redux. Main purpose is logging out state changes and actions handled by Redux.

redux-devtools

A more advanced extension useful when working with Redux. Comes in two flavors — a library to add to your application and a browser extension. Main selling point of Redux Devtools is the ability to export / import state as a JSON file (so your testers can share the state with developer when reporting bugs) and the “time travel” which allows you to rewind and fast-forward through a history of Redux reducer states.

redux-immutable-state-invariant

Immutability is one of the main assumptions of Redux, but sometimes a mutation slips through. Adding this middleware will help you track such errors by providing console messages when such a situation takes place.

rubber-duck debugging

No really, hear me out on this one.

Have you ever had a situation where you started to explain a weird bug to a colleague only to have one of those “oh FFS, THIS is what’s wrong” moments? There’s a name for that.

Know of any good tools or techniques?

If you know of any good tool or technique that is worth sharing with other React developers, please let me know in the comments bellow :)

I’d like to thank acemarke for his help while writing this post.