At Camunda, we have a mentoring program where junior and senior engineers come together to share their knowledge and experience to become better engineers. Very often, we  look at what we are currently working on and discuss potential solutions and problems that we encounter.

In one of these mentoring sessions, we came across some very interesting behavior involving console.log and React.Strict mode. After a bit of digging we came up with this minimal example: 

let i = 0;

function App() {
  i++;
  console.log("render count:", i);
  return i;
}

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById("root")
);

My mentee looked at this code and said “Okay, we are rendering the App component, this increases the i counter, prints it to the console and returns it. So the result is “render count: 1” in the browser log and 1 is rendered on screen.”

I knew of the intricacies of React.Strict mode and that it would cause the render function to be called twice. The idea is that this will help developers identify unintended side-effects in methods that should be side-effect free. You can read more about that here.

After working through it, we came up with an updated theory of what should happen: “React intentionally calls the render function twice, so i will be increased twice. We will see two entries in the browser console “render count: 1” and then “render count: 2” and the screen will render 2.”

But this is still not what was happening. If you run this code, there is only one console log saying “render count: 1”, but the screen shows 2. You can see this for yourself.

What is going on?

The only place where the value of i is increased, is directly followed by a console.log statement, so if i was set to 2, it should show up in the console.

It turns out that React is hijacking console.log and replaces it with a function that does nothing on the second render pass. Here is the code that does that, this is the Pull Request that introduced this behavior and here is an open Pull Request to add an opt-out option to the dev tools.

In our example the render function is indeed executed twice, which leads to i being 2 when it is rendered on screen, but only the first console.log call actually logs to the console, so it looks like the render function is only called once and i is only set to 1.

The Outcome

After discovering this issue, we brought it up in one of Camunda’s frontend engineering meetings to make all teams aware of this very specific behavior. We discussed that developers not familiar with StrictMode will try to use console.log debugging, to figure out why their functions are executed twice. If the logs for the second pass don’t show up in the console, developers might falsely assume that the function is only executed once.

I would even argue that it undermines the concept of StrictMode. Printing to the console is a side-effect that StrictMode is supposed to expose. Intentionally obscuring it not only makes debugging harder, it prevents developers finding rogue log statements in render phase lifecycle methods that could cause problems in production once concurrent mode lands.

But now that we are aware of this issue, we can avoid this particular pitfall and know how to deal with it should it come up when building new features or fixing issues.


Sebastian Stamm is a Principal Software Engineer at Camunda. You can follow his work on Twitter, Dev.to and https://stamm-software.com/.

  • Process Automation Centers of Excellence: the secret...

    Have you successfully implemented Process Automation technology in areas of your organization, but find yourself struggling to drive further adoption? Are organizational silos, ease of knowledge sharing and resistance to change slowing things down? You aren’t alone. Moving from pilot and lighthouse projects to a full Process Automation program is a challenge. But, there’s a solution — establishing Process Automation Centers of Excellence (CoE) to share best practices and drive organization-wide digital transformation. “If you had one team working on the pilot, and probably also the lighthouse project, they will not only have become very familiar with the technology and architecture, but will have learned a couple of valuable lessons the hard way. These are incredibly valuable experiences and you...

    Read more
  • Camunda Cockpit dark mode

    Community Questions: Camunda Web Apps

    On the last Thursday of every month anyone from the Camunda community can get their burning questions answered live on the Camunda Question Corner, and myself and Nele will do our best to answer them. We tend to pick a special topic for each Question Corner and bring along a knowledgeable special guest so that folks have the opportunity to get their deep-dive questions answered by qualified experts.  One of our more recent Question Corners took the special topic of the Camunda Web apps and we were joined by a developer who actually builds those web apps for Camunda — Martin Stamm. We got a lot of great questions, but having only 45 minutes to answer them meant that we...

    Read more
  • sneakers on pavement

    “Hello Cloud”

    Setting up your Telegram channel with Camunda Cloud  If you’re a runner, then you know it’s important to change your running shoes from time to time. I’ve run many miles with the Camunda Platform. I’ve used it for my own projects, for tutorials, and taught people how to use it in workshops. Now, it’s time to put on some new shoes: it’s time to automate a process with Camunda Cloud. If you’ve also been using Camunda Platform and are interested in what it looks like to move to Camunda Cloud, come for a run with me. In the continuing pandemic situation, I need to stay informed, and know as soon as the situation relaxes. I find myself checking the Corona...

    Read more