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/.
Camunda Developer Community
Join Camunda’s global community of developers sharing code, advice, and meaningful experiences
