As engineers, we review code on a daily basis. The code review process is something we’re used to, but maybe we’re underestimating the value it gives us?
In code reviews we share our knowledge, we make an impact and most importantly, we create common ownership over our code.
Good code review process aims to solve a few pain points, in this post I’ll cover the first point in a series of 4 points.

Building the right thing

Let’s say we were constructors (real constructors, with cement and everything 😅) and a new client asked us to build them the house of their dreams.
The client described us what they wanted, and we went straight to work.
1.5 years later, we shipped them an amazing house:

When our clients entered the house, they were shocked. The house wasn’t even close to what they wanted. Too many rooms, they wanted a single floor house and the infinite pool was supposed to to be on the left.
Looks like going “straight to production” wasn’t a good idea. We could have maybe create a model of the house and verify it satisfies our clients? Maybe even a sketch could work.

Same goes for a pull requests we work on. In order to “get it right the first time” (TM), we should aim to present a clear vision of what we’re going to implement and how we’re going to implement it.
This can either be by presenting the technical design ahead or even creating a draft PR (pull request) with a small prototype. The main thing to remember here is that if we’re presenting an early draft or unpolished work, we should notify our reviewer about that (in the PR’s description).

Another good approach to verifying we’re building the right thing is to enforce tests for every PR. When reviewing the code, starting with the test cases to understand what this PR is covering can be a good approach.

Lastly, when we open the pull request, we should not forget to attach a ticket and describe what we’re doing. This will help our reviewer get background about why and what we’re trying to solve.

Summary

This was a quick tip about code reviews, I’ll do my best to continue writing more tips related to code reviews :)
If you have any questions, feel free to ask here or on Twitter.

Thanks!

This post is also available in my personal site:
https://matan.io/posts/to-unit-or-integration

If you’re using one of the testing-library packages, you’re probably already familiar with the term “implementation details” and why we should not test those. If you’re not familiar with that term, here’s a quick explanation:

Kent C. Dodds 🌌 on X (formerly Twitter): "The more your tests resemble the way your software is used, the more confidence they can give you. / X"

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

Since implementation details aren’t something our users see, use or know about, they should not be part of our tests. I want to specifically emphasize one part of this sentence and the types of tests we need to adhere to it.

The way our software is used

Before talking about “the way our software is used”, it’s important to understand who are our users.

Usually when we think about the way our software is used, we think about our clients, the ones going from page to page, clicking the buttons and filling out forms. We should not forget about the other type of users: our fellow engineers, using the component’s API.

In order to resemble the way clients use our software, we should write integration tests that include pages, many components that interact with each other and also not forget to include the “plumbing” (eg. Data providers, Actions, Reducers and many more).
I mean, I’ve never seen an app with one button, have you?

This part of the principal leans hard towards “integration testing is the only valid approach”.

What does it mean for unit tests? are they useless? Well, no, they are not.

Our second type of users are engineers, and the way they use our software is entirely different.
Let’s say we build a TextField component. That component will be visible to our clients, but the ones actually using that TextField will be our fellow engineers.
In order to resemble the way they use our software, we should write unit tests that cover the API of that component.
We should render only that component and verify that it works as a standalone while making sure that it succeeds in providing the entire API it promises to its users.

The bottom line is that we should understand what’s the best way to imitate our user’s behavior and leverage our tools accordingly.
When we have “shared” components which are widely used within our project by other developers, we should be unit testing them to verify that their API works perfectly.
When we have a feature combining multiple components, we should use integration test to verify that this feature works perfectly.

Final words

I decided to write this down because I received this question multiple times as a Testing Library maintainer. Hopefully, you now understand why unit tests are still relevant even if we follow the important principal of “testing our software the way it’s used”.

Last but not least,
I hope everyone’s feeling well and keeping themselves safe!
If you have any questions, I’m here and also on Twitter.
Feel free to ask or comment, I’d love to hear your feedback or help with any dilemmas you have :)

Thanks,
Matan.

If you wanted to use an Emoji as a favicon but wasn’t sure how to do it or if it’s supported, then here are all the details you need to know.

Support

To simply use an emoji as a Favicon, we’ll need to use an SVG as our Favicon. This is supported in all ever-green browsers besides Safari.

Method

<link rel="icon" type="image/svg+xml" sizes="any"        href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>🥬</text></svg>"/>

Adding this code snippet to your head section will give you a nice emoji favicon. Cool thing about this is that using sizes="any" gives us an option to support all resolutions and all sizes in just one line. This works only because we’re using image/svg+xml and SVG is “Scalable Vector Graphic”.

Last but not least,
I hope everyone’s feeling well and keeping themselves safe.
If you have any questions, I’m here and also on Twitter. Feel free to ask or comment, I’d love to hear your feedback or help with any dilemmas you have :)

Thanks,
Matan.

Some people tend to think that our work as Software Engineers is all about coding. I can’t disagree more.

In our daily work, we are involved in many situations that may affect other people around us and that’s why I believe caring should be a major part of our work.

We continuously iterate on our code to make it better (admit it or not, you care for your code), can we incorporate caring in our daily work even when it’s not related to the code we write? How can we be more active when it relates to caring?

Caring is “Feeling or showing concern for or kindness to others” (Merriam Webster). We have a lot of opportunities to show we care in our day to day life, we just need to pay attention to them.

Caring in your daily work

In many cases someone else will have to read the code we write so the fact we can understand what is going on is not enough. Consider this quote from the book “Clean Code”:

“Clean code always looks like it was written by someone
who cares” — Micheal Feathers

Caring about others (and your future self) is crucial for your code to be useful over time.

Another aspect of caring in our daily work is considering the fact that your work is part of a bigger project. This means that if you care about the success of the project, you need to make sure you document your work and share your knowledge when needed, so other people can support what you did. Same goes the other way around when you’ll need to support what your teammates did. Caring about the project will create common ownership among all of the team and not just individuals.

Caring in your team

Development projects usually involve people with different functions: from QA, to UX designers, Backend devs, Frontend devs, Product managers etc. We can also assume that your team may be constructed of different seniority levels within the same functions.

By caring about other people even if we are not responsible for their part of the work, we can improve the velocity of the greater team and reduce friction. Sometimes it means doing a little extra work that may not be “in our court” like helping the QA or the UX Designer. Sometimes it means explaining what you did another time so it’s clear and sometimes it is providing feedback or talking to someone having a bad day.

Being proactive by asking, commenting and sharing your opinion and interest will take your caring to the next level and will encourage others to do the same.

Caring in the community

On top of our work, we are all part of developer communities.
Contributing back to the community is the ultimate form of caring since it doesn’t necessarily benefit you.

One great way to show you care is to contribute to open source projects.
Using your free time in order to provide others with a way to get things done easily and quickly without expecting anything in return means caring.

Contributing to OSS can come in many forms.
You encountered an issue? Try to find the time to submit a PR. If you don’t have the time, open an issue, let everyone know that you found something.
You loved a feature? reach out, tell people you love it. There are many communication channels nowadays (from discord, to twitter to even GitHub discussions) so you can reach out to almost anyone.

I got into open-source by showing I care and answering open issues in Testing-Library. I have to admit, it felt really good. The small appreciation from someone you helped, means a lot.

Final note

Caring takes work. You need to be proactive and mindful to show you care, but I promise you, it is definitely worth it. It will make you and everyone around you better at what you do.

Last but not least,
I hope everyone’s feeling well and keeping themselves safe!
If you have any questions, I’m here and also on Twitter. Feel free to ask or comment, I’d love to hear your feedback or help with any dilemmas you have :)

Thanks,
Matan.

This post is also available in my personal site:
https://matanbobi.dev/posts/stop-using-container-presentational

The “Container/Presentational” Pattern used to be the best practice when using redux or any other store management package.
It was explained thoroughly by Dan Abramov and Michael Chan.
If we want to keep it short, a container usually holds the data fetching logic and data access to store. On the other hand, a presentational component is more generic and just present the data it gets as props.
This pattern was common before React Hooks were introduced and probably every developer using React with classes has seen or used it.

But in the world of hooks, this approach can cause serious performance issues (we will cover those later on).
Moreover, the Redux best practices now suggests we should connect more components to read directly from the store (which is quite the opposite to this pattern).

“Prefer having more UI components subscribed to the Redux store and reading data at a more granular level. This typically leads to better UI performance, as fewer components will need to render when a given piece of state changes.” (The redux docs)

But, what’s the reason behind this rule?

Our example app

I’ve built a small app with a sidebar fetching all the Pokemons (with a Select that decides how many Pokemons to fetch), and a right box showing the selected Pokemon. Clicking on a Pokemon name at the left, will change the image and fetch the relevant data.
The UI looks like this:

In the first approach, I decided to use connect on a container, query all the data from the store and also mapDispatchToProps so I’ll be able to dispatch some data fetching.
I passed the data to my components using props (the example uses styled-components but the actual styles were left behind):

My components just fetch the data and show it based on the props.
I opened the React profiler, recorded a click on a Pokemon name and saw the renders that it triggered.
Here’s the screenshot:

What do we see here?
When clicking on a Pokemon name on the left sidebar, we initiated two renders. In the first one we see the PokemonsSidebar was rendered and it took 1ms. But, why was it even rendered? It didn’t change, nor did it’s props. The reason for that is that the parent component was rendered because of a change in the redux store, so all of it’s children should also render.
We can also see that the whole Render duration was 13.6ms, that’s because inside the PokemonsSidebar we have 150 li‘s that rendered again for no reason because their parent re-rendered.

In the second approach, I refactored my code to useSelector and useDispatch. My presentational components will be connected directly to the store and dispatch the actions.
Here’s my component’s code:

Let’s see the profiler screenshot:

As we can see here, the PokemonsSidebar didn’t re-render because it wasn’t subscribed to the selectedPokemon data from the store, thus all of it’s children didn’t re-render. The Render duration this time is only 0.9ms (compared to 13.6ms)!

These numbers may sound negligible but that’s just an example. My app isn’t complicated and there’s just one component that shouldn’t render (and it’s children). What if I had more components? and my components had a heavy render?

Why does it happen?

Since we’re using function components, whenever our parent component renders, the whole tree is marked for render. React then recurses over all children and tries to render them. If our function components aren’t wrapped with React.memo they will automatically re-render even if their props or state didn’t change. We need to bear in mind that memoization also has some performance impact so wrapping all of our components with React.memo isn’t always the best approach.

Disclaimer

As you can understand from the last section, this isn’t a Redux only issue, but rather a React behavior. The “container/presentational” pattern can still be a valid solution as long as the impact is taken into consideration.
It’s important to note that this isn’t just a useSelector vs connect issue. I’ve seen examples creating a container with lots of useSelectors just aiming to mimic this “container” approach and I’ve also seen examples of connect on many components.

Summary

In this post, we’ve covered an important rule that was somewhat hidden inside the whole Redux style guide. If you still haven’t read the style guide, I urge you to do it. It contains many rules that will make your work with Redux straightforward and clear.

I hope everyone’s feeling well and keeping themselves safe!
If you have any questions, I’m here and also on Twitter. Feel free to ask or comment, I’d love to hear your feedback!

Thanks,
Matan.

Read More:

The repo containing this example
The Redux best practices
Presentational and Container Components by Dan Abramov
Container Components by Michael Chan

This post is also available in my personal site:
https://matanbobi.dev/posts/introducing-the-async-cookie-store

Are you sick and tired of weird ways to get cookies fromdocument.cookie ? Hate it that you don’t know whether the cookie you set was actually saved or not? Introducing: Cookie Store API, available on Chrome version 87!

Motivation

We all use HTTP Cookies almost daily, but working with them was never an easy task.
The cookies interface is overly complexed and contains performance issues. Saving all of the cookies in document.cookie which is part of the Document Object Model from October 2000, seems like a pattern that doesn’t correspond to the javascript we write these days.

The Cookie Store API aims to improve this by providing an asynchronous alternative to document.cookie and exposing HTTP cookies to service workers, which will also benefit performance. It’s available on Chrome Browser starting from version 87 but still didn’t land in any other major browsers.

Get Cookies

Getting a cookie always looked odd to me. Why do I have a full string containing all of the cookies? Getting a specific cookie always seems like an over-complex solution, using some regex or looping over the document.cookie value. In fact, all of us who need cookies probably have this util taken from some StackOverflow answer in their codebase:

In the new way, all we need to do is use the cookieStore object and call its get function. Don’t forget that this returns a promise so you await for its result and if something wrong happened, it would throw an error:

No more looping over a cookies string! Amazing!

Set Cookie

Don’t you just hate setting a cookie? The API seems so old-fashioned.

Following what we wrote about getting cookies, the setCookie util probably looks somewhat like this:

After doing that, we’d probably also want to know that the cookie was successfully created. So we’ll use the getCookie util from before and loop over the cookies string to find that cookie.

In the new API, what you’ll need to do is use the cookieStore object and call the set function with the params, that’s all.

After calling that function, as long as we didn’t get to the catch block, we can be 100% sure that the cookie was saved successfully, and we don’t need to loop over anything or call cookieStore.get to see that it was saved.

Delete Cookies

To delete the cookie, we probably had something similar to this util:

It will basically set the cookie date to an old date and count on the browser to delete it since it’s already expired.

In the new way, you’ll need to call the delete function:

Once again, as long as we didn’t get to the catch block, you can 100% be sure that the delete happened.

Monitoring Cookies

A cool thing you can do with the new Cookie Store API is know when the cookie object was changed and act on it:

Summary

It looks like the Chrome team tackled a problem we took for granted for a long time, and I do believe that this is great progress towards a better web!
If you’d like to read more, you can visit the Cookie Store API Draft.

I hope everyone’s feeling well and keeping themselves safe!
If you have any questions, I’m here and also on Twitter. Feel free to ask or comment, I’d love to hear your feedback!

Thanks,
Matan.

This post is also available in my personal site:
https://matanbobi.dev/posts/introducing-the-async-cookie-store

If you were a part of the Frontend community for the past year and a half, the term “Concurrent” appears in almost every second tweet.
It all started with Dan Abramov’s talk Beyond React 16 at JSConf Iceland 2018. Dan showed how the React team built a generic way to ensure that high-priority updates don’t get blocked by a low-priority update. The React team called this mechanism “Time Slicing” and it was based on a Scheduler package they created.

This scheduler is called the “Userspace Scheduler” and was later used as a case study for Google Chrome developers for their work on a built-in scheduling mechanism.

The Problem

Let’s take Lin Clark’s analogy from her talk in React Conf 2017 and compare our code to a Project Manager. Our project manager has 1 worker, the browser, but our worker is pretty busy, he’s not 100% dedicated to our JavaScript code. It uses one thread to run our code, perform garbage collection, layout, paint, and more.
This issue buried the main problem: long-running JavaScript functions can block the thread and cause our worker to tip the balance and miss layout, paints, and more. This is a steep slope that immediately leads to an unresponsive page and a bad user experience.

The Solution

This problem is usually tackled by chunking and scheduling main thread work. In order to keep the browser responsive at all times, you break long tasks to smaller ones and yield back the control to the browser after an appropriate time. The time is calculated based on the current situation of the user and the browser.
But wait, how will I know to split the work based on time on my own? How do I even yield back control to the browser? 🤔
To solve these problems we have Userspace Schedulers. So what are they?

Userspace Scheduler
A generic name for JS libraries built-in attempt to chunk up main thread work and schedule it at appropriate times. These libraries are responsible for doing the work and yielding the control back to the browser without blocking the main thread.
The main goal: Improve responsiveness and maintain high frame-rate.
The main examples are React’s Scheduler package and Google Maps Scheduler.
These schedulers have been effective in improving responsiveness but they still have some issues, let’s go over them:

1. Determining when to yield to the browser — Making intelligent decisions of when to yield is difficult with limited knowledge. As a Userspace scheduler, the scheduler is only aware of what’s happening in its own area.
   The React’s scheduler, for example, defaults to 30 FPS for every unit of work (which means around 1000ms/30=33.333ms) and adjusts it to higher a FPS rate if possible. Having said that, React’s scheduler still checks between frames to see if there’s any user blocking task pending on the main thread and if there is, it yields back control to the browser. React does that by using scheduling.isInputPending(), we will talk about this function in the APIs section.
2. Regaining control after yielding — When regaining control back from the browser, we will have to do the work of the same priority without returning back to the paused task until finishing the other work. That happens because we yield to the event loop and write a callback but there can already be callbacks waiting for that priority.
3. Coordination between other tasks — Since userspace schedulers don’t control all tasks on the page, their influence is limited. For example, the browser also has tasks to run on the main thread like garbage collection, layout, etc. and userspace schedulers can’t impact these tasks.
4. Lack of API to schedule chunks of the script — Developers can choose from setTimeout, postMessage, requestAnimationFrame, or requestIdleCallback, when choosing to schedule tasks. All of these have a different impact on the event loop and require a thorough knowledge of how it works.
   The React’s scheduler for example uses setTimeout as shown here.

Main Thread Scheduling API:
Since all current solutions have limitations, the Chrome team decided to create API’s for scheduling main thread work. These APIs are all gathered under the “Main-thread Scheduling API” title and are currently an experimental feature not yet deployed to production nor beta version.

How can we try it?

To get the new Main Thread Scheduling APIs we need Chrome version 82.0.4084.0 and higher.

This version is available in Chrome’s beta version or in Dev and Canary versions. I recommend downloading the Chrome Canary version since it can live alongside our current Chrome version. A download link can be found here.
Once downloaded, we need to turn on the feature-flag called Experimental web platform APIs here: chrome://flags/#enable-experimental-web-platform-features

API’s

scheduler.yield: When calling this function, we will yield to the event loop, such that a continuation task will run after the user agent services higher priority work, but before tasks of the same priority are allowed to run.
This function will return a Promise which will be resolved after the event loop services the higher priority work. We will also be able to specify a priority to the function scheduler.yield(‘high’) stating we want control after tasks with this priority or higher were executed.

scheduling.isInputPending(): This function will let us understand whether we have any pending input events waiting in the event loop and in that case we can yield back to the browser so it will handle these input events. This function is actually being used in React’s Scheduler.

requestPostAnimationFrame: This API isn’t implemented yet and is more of a draft API. This API will act as a bookend for the requestAnimationFrame functionality, an “after paint” callback.
To understand this — The callback of requestAnimationFrame runs just prior to the rendering and the callback of requestPostAnimationFrame will run immediately after the rendering. This can be used to get a head-start on long running task and starting to create the next frame as soon as possible.

TaskController: This API is the main API for controlling tasks, it contains a signal object with the following structure:

{
  aborted: false,
  onabort: null,
  onprioritychange: null,
  priority: "user-visible"
}

The TaskController Object inherits its functionality from AbortController and the signal inherits its functionality from AbortSignal so when using it, we will be able to abort a task that wasn’t executed yet.
API looks like:
const controller = new TaskController(“background”)
and to get the signal we simply write controller.signal.

scheduler.postTask : This API can be used to post a task with a priority or a delay.
The postTask function accepts a callback function and a signal. This signal can either be the one created from the TaskController or just an object with priority property or delay priority containing a number.
The API shape is similar to other async API’s (fetch for example): scheduler.postTask(callbackFunction, { priority: 'background' })

It’s important to note that creating a callback with background priority can also be done by using requestIdleCallback. Having said that, posting and managing multiple priorities is much more complicated without these API’s.

There are more API’s that fall under the umbrella of Main Thread Scheduling but these are the ones I found important to note here.

Example

An important note is that I’m not using React’s Concurrent Mode. I’m trying to show a solution based only on the new Scheduling API and not on React’s Userspace scheduler (disclaimer: even the non Concurrent Mode React works with a scheduler but it doesn’t contain the time-slicing features).

Another small note, I’ve based my example project on Philipp Spiess’s project for “Scheduling in React” post.

Here’s a gif showing the app in action, try to look at all the details on the screen and what happens when I try to type:

On the screen, we see a header with an animation working with requestAnimationFrame (rAF), a search input, and a few pokemon (there are actually 200 rendered).
So why does it get stuck? 🤔
What happens is as follows: on every keypress in the input, the whole pokemon list renders (I passed the search string to every pokemon so we will mark the search substring) and every pokemon has a synchronous timeout (a while loop of 2ms).
As we said, in my app I have 200 pokemon, leading each keypress to cause a render of about 400ms. To top it up, on the event handler I also simulated a synchronous heavy computation function of 25ms.

Let’s look at a performance screenshot of what’s happening:

In the red box, you can see timings that I added or React added by itself.
The yellow box contains the call stack breakdown for each keypress.

Here’s a quick breakdown of what’s happening:
Every keypress leads to a long render (about 400ms), causing a Frame Drop(this can be inferred from the red triangle I wrapped with a blue circle).
Frame drop happens when the main thread is too busy with running our JavaScript code so it doesn’t get the chance to update the UI so the website freezes.
Before every render, in the timings section (the red box) we can see a small box I wrapped by green ovals, that’s our heavy computation function, it takes around 25ms as we can see in the tooltip. But sometimes, we don’t need that heavy computation to happen right away, maybe we can do it later. With Main Thread Scheduling API, we can do exactly that.

To do that, we need to change our event handler. At the moment it looks like this:

Let’s use postTask and see the performance analysis:

So what did we see?
Our heavy computation function now happens at the end (wrapped in the timings section with a green oval), after all the renders happen. The main difference is for our users, instead of waiting 3800ms for the UI to be interactive, they now wait 3600ms. That’s still not so good but even 200ms is a difference.

Another amazing feature is to be able to cancel a task if it wasn’t executed yet.
In the previous example, we had a heavy computation function happening on every event, what if we would want it to happen only for the last event?

So what’s happening here? here’s a quick explanation:
We’re aborting the last signal we had and create a new TaskController every time we enter the event handler. That way we cancel all the tasks with the aborted signal attached to them. Below we can see the performance screenshot for this code, inside the timings section in a green oval we see that only the last task we created was executed.

Summing it up:

We live in exciting times for the web development community. It looks like everyone involved truly aims for a better web and a better experience for our users.
I hope everyone’s feeling well and keeping themselves safe!
If you have any questions, I’m here and also on twitter, feel free to ask or comment, I’d love to hear your feedback!

Thanks for reading!
Matan.

Browsing multiple projects, I encountered a recurring pattern when trying to write a custom render for components that use Providers (React-Redux’s Provider, React-Intl’s IntlProvider for example).
This pattern usually looks like this:

This function is nice. It creates a utility that lets us call it whenever we want to test a connected component. The only problem is, it’s limited and causes an inconsistent behavior.
Usually, our app will work with several Providers, not only one, and this solution becomes squeaky when we try to add more Providers to it.
Another thing is that using it will cause inconsistency since we will call renderWithRedux every time instead of calling render as we usually do and we will also import the renderWithRedux from our test-utils file and all the other RTL utils like screen and fireEvent from @testing-library/react.
We will probably get something like this:

To fix this, React Testing Library lets us create a custom render function.
I have to be clear. This functionality isn’t new, it’s just not well known or used (in most of the projects I’ve seen lately).
To create a custom render function, we don’t have to work hard.

By doing this, we’ve created a function that uses the Wrapper option of RTL’s render. On top of it all, we also exported all the other functionalities so now we can import our render function and all the other React Testing Library functionality (fireEvent , screen etc.) from the same place.

Let’s take an example of a simple connected, translated, styled date component (This is an imaginary use case 😅):

We can see that I imported render and screen from our test utils, and this test is actually using all of our Providers: ThemeProvider, React-Redux’s Provider and IntlProvider.

That’s it! I hope I made everything clear.
If you have any questions, feel free to ask.
I’m here and also on twitter.
Thanks for reading!

This post is also available in my personal site:
https://matanbobi.dev/posts/wait-youre-not-using-react-strictmode

Last month on twitter, I encountered a tweet by Sebastian Markbåge a React core team member asking developers if their app is running in <StrictMode>:

The results blew my mind, 70% of us aren’t using it and never tried it!
At the moment, StrictMode helps us adapt our app to ⚡ Concurrent React ⚡ (Will be covered soon).
With React-Conf just around the corner (24–25/10), we still don’t know what the keynote by Tom Occhino and Yuzhi Zheng will be about, it looks like Concurrent mode might arrive sooner than we thought.

In this post I’ll cover all the warnings produced when using StrictMode, how they are related to Concurrent React and what actually is Concurrent React.
I promise you that by the end of this post, you’ll probably want to add it to your react app 🙂

What is it?

React StrictMode is a feature added in version 16.3 and aimed to help us in finding potential problems in an application.
If you see warnings in StrictMode, you will likely encounter bugs when trying to use Concurrent React.

Like Fragment, StrictMode does not render any UI, it only activates checks and adds warnings at runtime.
StrictMode checks are done in development mode only and will not affect your production build.

Whats the motive?

Concurrent React is React’s new ability to concurrently render, suspend, and resume rendering trees in the background while remaining interactive (not destroying old trees while rendering the next).
Concurrent React’s main features are Time Slicing and a new Scheduler mechanism but it may also come with more features like React Suspense (for asynchronous data fetching) and Caching.

We know that Facebook are dogfooding Concurrent React for a while now in the new Facebook web (discovered in F8), iterating on bugs and working to get a stable version.

Just so you’ll get a glance of Concurrent mode’s power, an unstable example of Time-slicing was shown by Dan Abramov in his talk “Beyond React 16” and can be found here.
The example above shows Time slicing and scheduling, using it in Synchronous mode is the way React works now and using it in Asynchronous mode is an unstable example of Concurrent mode.

Concurrent mode is actually a different paradigm than the way we wrote JavaScript up until now, we should think of it more as a multi-threaded model, which schedules our work on a priority base.
As this paradigm is different, we need time and practice to get rid of old bad habits, trying out StrictMode is a great way to start.

How to use it?

All you need to do in order to enable StrictMode (from version 16.3) is to wrap the part you want in your app with <React.StrictMode>.
You can wrap the whole app or only specific nodes.
Here’s an example of wrapping the whole app:

Right after doing that you’ll be able to see warnings in your developer tools console.
At the moment, StrictMode helps with a few specific issues, we’ll cover them up and see how the warnings look like.

Detecting unexpected side effects:

Conceptually, React works in two phases, the Render phase and the Commit phase.
The render phase is the expensive part, it’s when React decides what changes need to be made to the DOM. In this phase, React will call your render function and run a render lifecycle which includes: constructor, componentWillMount, componentWillReceiveProps, componentWillUpdate, getDerivedStateFromProps, shouldComponentUpdate, render, setState updater functions.
The commit phase is the part when React flushes the changes (additions, updates, removals) to the DOM, usually a quick phase. In this phase React also calls the componentDidMount and componentDidUpdate lifecycles.

While these phases will probably stay the same in Concurrent mode, the plan is to break the render phase into small pieces so we will be able to pause and resume the render phase so we won’t block the browser with long renders.
In fact, this means that React may trigger a render lifecycle more than once before committing the changes or even trigger a render without committing it (for example an error was caught or a higher order event happened).
So we can understand that the lifecycles in the render phase can be called more than one time, therefore it’s important that they will not contain side effects, if they will contain side effects, it may cause memory leaks and invalid state.

In order to help with that, in development mode only, StrictMode will double invoke the next methods from the lifecycle: constructor, render, setState updater function and getDerivedStateFromProps so you will be able to see if your code breaks or behaves different than how you expected.

Identifying components with unsafe lifecycles:

The ‘Unsafe Lifecycles’ term was introduced in release 16.3 of React, it means that some of the legacy component lifecycles tend to encourage unsafe coding practices, they were misunderstood and misused in codebases. The main issue is that their potential misuse may be even more problematic for concurrent react (creating side-effects in places that aren’t made for that may cause problems when updating them concurrently). That’s why componentWillMount, componentWillReceiveProps and componentWillUpdate were all flagged with UNSAFE_ prefix.
In StrictMode you will get a list of every component that still uses these lifecycles, that comes in handy to ensure that a third party library isn’t using these lifecycles.

Using unsafe lifecycles will produce this warning:

To help with refactoring your own code, there’s a code-mod that will rename all unsafe lifecycles and add the UNSAFE_ prefix, though keep in mind that this only removes the warning, it doesn’t remove the use of an unsafe lifecycle.

npx react-codemod rename-unsafe-lifecycles <path>

Warning about legacy string ref API usage:

Although being the convenient way, legacy string refs have several downsides. The main one was that they were resolved synchronously, which means they will create a problem when rendering will happen concurrently.
To fix this warning you have two options:
From version 16.3, Using createRef is the recommended way to create refs.

If you’re using an older version, the recommended way is a callback ref to make the ref creation “asynchronous”.

Lastly, you can also refactor your component to use Hooks, and use the useRef hook.

Using string refs will produce this warning:

Warning about deprecated findDOMNode usage:

React used to support findDOMNode to search the tree for a DOM node given a class instance.
There are a few problems with this approach, the first one is that it might cause an issue with refactoring since a parent component used to be aware of it’s children implementation details if it used findDOMNode to get a child element, The second problem is that findDOMNode returns the first child found, but in a world with Fragments we sometimes have multiple children rendered by one component.
Using findDOMNode is usually unnecessary since you can always create a ref directly to a DOM node (as we showed previously), if you do need something like findDOMNode, you can create a ref and use Ref Forwarding in your custom component in order to get the underlying DOM element.

Using deprecated findDOMNode will produce this warning:

Detecting legacy context API:

This isn’t Concurrent mode related issue but still addressed within StrictMode. React previously shipped with an experimental context API which was error-prone, and will be removed in a future major version. It still works for all 16.x releases but if you’re using it you should migrate to the new Context API.

Using legacy context API will produce this warning:

Summing it up:

In this post we covered all the warning you’ll get when using StrictMode but the main issue isn’t really about StrictMode, it’s more about getting rid of old habits that will keep us from not using Concurrent mode when it becomes available (hopefully on 24/10 🤞).
Some users may still be blocked from fixing all the changes I’ve covered here like developers using componentWillMount for server side rendering. These issues will probably be addressed by the React team if weren’t addressed already when implementing Concurrent mode in the new facebook.
Another type of users that may be blocked are developers still using legacy 3rd party packages, in that case I recommend upgrading packages or replacing them with new ones since they probably aren’t maintained anymore.

Hope I convinced you to add StrictMode to your app and that you’ve realised what’s coming up for us as React users.
If you have any questions, feel free to ask.
I’m here and also on twitter.
Thanks for reading!

React as we all know it, is changing. As a frontend developer with React experience for the past 3 years, selling me these changes was quite hard.
I’m here today as the seller and not as the buyer, hoping I will catch you in the fever I got once I understood what’s behind all these changes :)

After the React team announced Hooks, and pushed functional components as a “solution for all our problems”, this thought ran in my head, why should we use React’s defaultProps and not ES6 Default values for functional components? Then I found this RFC that pretty much says what the React core team thinks about the idea.

In this post I’ll cover my thoughts and share some performance conclusions.
I’ll start with a simple explanation regarding defaultProps and ES6 Default Values. To avoid confusion, let’s decide to call React defaultProps React def. values and ES6 Default Values ES6 def. values. If you’re already familiar with the syntax, feel free to jump to the conclusions part.

React def. values:

Since React v15.5, runtime type checking for component’s props moved to a unified package called prop-types. This package gives us the ability to type check a component’s props and give it default values, for example lets look at a Greet component:

const Greet = ({firstName, lastName}) => {
  return (<div>{`Hi ${firstName} ${lastName}`}!</div>)
}

Greet.propTypes = {
  firstName: PropTypes.string,
  lastName: PropTypes.string
};

If we try to render Greet without giving it props:

const Header = props => {
  return <React.Fragment>
    <Logo/>
    <Greet/>
  </React.Fragment>
}

We will get something like this:

Hi undefined undefined!

defaultProps lets us avoid this scenario by setting default values to props:

Greet.defaultProps = {
  firstName: 'John',
  lastName: 'Doe'
};

so when not passing the relevant props we will get:

Hi John Doe!

ES6 def. values:

Another option we can use in functional components only, is setting default values with ES6 Destructuring assignment syntax.
Let’s take the Greet component we’ve created above and change it so it will contain default values.

const Greet = ({firstName = 'John', lastName = 'Doe'}) => {
  return (<div>{`Hi ${firstName} ${lastName}`}!</div>)
}

As simple as that.
So what should we use?

As everything is in programming, it’s a tradeoff, let’s see why.

Advantages and Disadvantages of React defaults:

While using defaultProps is the best practice at the moment, it looks like this will change in the upcoming versions of React.
The main advantage defaultProps has is it gives us a unified way of setting default values to props in both class components and functional components. The second advantage is that the syntax is simple and straightforward.
The main problem with defaultProps, lies in its implementation.
Let’s have a look at React.createElement implementation at the latest stable version (16.8.6).

We can see that some stuff happen when calling to createElement with the props object, but the main issue is the defaultProps check. If we have defaultProps, we iterate over them and check if we already have a value in the props object, in case we don’t have a value we assign it the default. This happens every time we call createElement.
Let’s have a look at a small timing example I took with the Greet component we just built (The test was made in a development build of React).
All I did was adding console.time() at the start of createElement and console.timeEnd() at the end.

With defaultProps, createElement time: 0.01123046875ms
Without defaultProps, createElement time: 0.003662109375ms

That’s three times slower for that simple component and it contains only two defaultProps!
Just a quick disclosure, this doesn’t mean adding defaultProps will increase the render time by three, it just adds some milliseconds as it iterates over the defaults.

Advantages and Disadvantages of ES6 Defaults:

The main advantage default values has is that it’s a native syntax added in ES6 and supported in almost all browsers (except IE11) as a part of destructuring assignment.
In my opinion, the bigger problem with default values is that they create a difference between how we set default values in class components and how we set them in functional components, as setting a default value to a prop isn’t available in a class, the old class components will still have to use the old propTypes way, thus creating another difference between these two types of components. This problem will disappear in time since the use of class components should decline with hooks.

For the second problem we’ll have to change the Greet component a bit,
let’s change the component so it will accept a user object instead of firstName and lastName.

const Greet = ({user = { firstName: 'John', lastName: 'Doe' }}) => {
  return (<div>{`Hi ${user.firstName} ${user.lastName}`}</div>)
}

What’s the problem with the example we created? That’s right, immutability. The object we created as a default value will be recreated in every function call, so if we pass it down to a child component, the component will get a new reference every time and will cause a render on each parent render.
To fix that problem we will need to create the default value globally as a const so the reference won’t change:

const defaultUser = { firstName: 'John', lastName: 'Doe' };

const Greet = ({user = defaultUser}) => {
  return (<div>{`Hi ${user.firstName} ${user.lastName}`}</div>)
}

When using default values on latest browsers that don’t need to transpile destructuring assignment, it can even lead to a smaller bundle size. On the other hand, when using it in browsers that do need to transpile it, it may lead to a bigger bundle size since destructring assignment default values transpiles pretty weird.
I made a small example based on CRA with only prop-types and styled-components added. The example is made of 10 components, each one of them contains defaultProps.
Let’s take a look at a bundle size comparison after gzip:

Without defaultProps and transpile of default values: 55.969KB
Without defaultProps and not transpiling default values: 55.945KB
With defaultProps: 55.979KB

It looks like the difference to the bundle size is minimal.

Summing it up:

• React def. values lets us have a unified way of setting default values.
• React def. values will be slower the more default values you set.
• ES6 def. values may reduce your bundle size if deploying to browsers that already have destructuring assignment enabled.
• When using ES6 def. values you have to remember the pitfalls and create non primitive values upfront so they won’t cause a render on child elements.
• The React team decided on ES6 def. values as a way to set default values for functional components. A warning was already added as a part of the process to deprecate defaultProps in functional components.

It looks like we will see changes like what I talked about in the upcoming version of React, and it’s all a part of making React better for us the developers and for our users. The React team is working hard on tackling performance issues and changing the way we see the web now.
Keep up the great work React team ❤️

Hope I sold it well, but if you have any questions, feel free to ask.
I’m here and also on twitter.
Thanks for reading!