• React Today and Tomorrow and 90% Cleaner React with Hooks
  • 【React Conf 2018】React Today and Tomorrow
  • React Today And Tomorrow Part I — Chinese And English subtitles
  • React Today and Tomorrow – Part I
  • Address: React Today and Tomorrow — Part one
  • Speaker: Sophie Alpert
  • English subtitles from: YouTube machine Translation
  • English proofreading, translation, typesetting: Ivocin

Updated November 30, 2018, Part 2 has been updated: React Today and Tomorrow (picture version) – Part 2. 【React Conf 2018】React Today and Tomorrow with Chinese and English subtitles.

React today and Tomorrow I — Status and problems

Good morning. Hello and welcome to the React Conference. I’m very excited to be here today. I’m very pleased to be able to open with you.

My name is Sophie Alpert and my profile is Sophiebits.com. I’m the development manager of the React core group at Facebook.

The React of today

The React you’re using is doing a great job. We’ve increased NPM downloads by 70% in a year. React Dev Tools has been installed over 1.25 million times in the Chrome Developer Tools extension.

Here’s a list of companies that use React. At this point, the list is so long that it’s hard to tell how many companies use React from year to year.

Let’s look at another set of data. Let’s look at Google Trends, which reflects web search traffic. As you can see, the React searches are increasing all the time. Hopefully this data shows that more people are using React, rather than React becoming more confusing. (laughter.)

Well, just for comparison, we compared jQuery searches, and we just surpassed jQuery searches for the first time in history. (Cheers and applause.) But it also shows that we still have a lot of room to grow.

I was delayed while I was writing the speech. Because I’m curious what’s more popular than React. Oh dear. (Laughter) When I made a joke. Well, I find React is more popular than renewable Energy. (laughter.)

React is also more popular than orange juice. (Laughter) Think about how often orange juice is used.

And React is more popular than renewable energy and orange juice combined. So I think we have reason to be very proud.

The mission of the React

But beyond the numbers, what I really want to talk about today is React’s mission. Well, since React launched in 2013, our number-one goal and mission has been to make it easier for developers to build great UIs.

So when we want to add new features, we usually do it with a lot of thought. There are a lot of things to consider when deciding whether to add a new API. If adding a new API lets you do something you couldn’t do before; Adding an API is valuable if you can significantly simplify the code and libraries in your components, resulting in less work for you and less code for users to download. Or if the new API helps us implement the best practices of code splitting, if it makes it easier to split the code in your app into multiple packages, we hope your app will eventually run faster. That’s why we announced the addition of aN API like React. Lazy two weeks ago. You may have noticed the API.

But think about React’s mission — to make it easier for developers to build great UIs. There are a number of ways we can do this. One is that we try to simplify complex things. If you watched Dan Abramov’s talk at JS Conf in Iceland, you can get a preview of “Suspense”, the problem we use to significantly simplify data fetching, code splitting, and asynchronous data dependencies in apps.

Another way we tried to improve React was to improve performance. If your app is faster, your users will be more likely to use it. On the other hand, if your app is slow and slow, your users will not have a good experience. So we’re trying to make React itself run faster, and if React gets out of the box fast, you’ll save a lot of time optimizing your own code.

More recently, Dan talked about improving performance in Icelandic JS Conf, and we call it “Time Slicing”. “Time Slicing” ensures that the most important renderings in your app get executed first, unblocks the main thread, and makes your app run faster.

The third way is to use developer tools to help you debug and learn more about your app. From the beginning, React included dev-friendly warnings to help developers point out problems in case they weren’t noticed.

And our React Dev Tools extension lets you examine and debug your component tree. In React 16.5, we introduced a new feature called Profiler. It’s the second… (I don’t know what’s wrong with this remote)… The second TAB bar on the graph is the Profiler TAB bar, which helps us understand what’s going on in your app and optimize it better.

So three new features in Suspense, Time Slicing, and Profiler are things we’ve been working on for the last year. We really want to say more about these three features. But that’s not what I want to talk about here today. You can wait until tomorrow, Andrew and Brian are going to talk about that in the morning.

What else is wrong with React?

Now I want to step back and focus on some other issues. My question is, what’s wrong with React now? I have come up with three questions that I want to discuss with you here.

Logic reuse

The first problem is the problem of logical reuse among multiple components.

In React we mainly use components to build our applications, and there are two main patterns for components to reuse code: they are higher-order Components and Render props.

These two modes are fine for some scenarios, but they also create a major drawback. In more complex scenarios, you have to take them out and refactor your app. This leads to a problem I call wrapper hell.

Well, we often see component trees like this. (Screams and laughter.) And this nesting makes it difficult to track the app’s data flow. It would be nice to be able to reuse this kind of stateful logic without having to change the hierarchy of components.

The giant component

The second problem I want to address is giant components, whose logic is messy. Looking at a React component with thousands of lines of code, you can see that the logic is spread out over many different lifecycle functions, which can be very difficult to trace.

Let’s look at an example. Here’s a class component, and in its componentDidMount method, it does a few things: It subscribing to a data store, then sending a network request, and finally starting a timer.

So, if we look at the componentWillUnmount method, we see basically the exact opposite code: you first need to unsubscribe the storage, then cancel the network request, and finally stop the timer.

When we wanted to implement the componentDidUpdate method, the logic in it was more tricky. Because you need to compare old and new properties, and then repeat the same task logic inside the other lifecycle functions again.

Well, in this example, each request is only one line, so this example is actually much simpler than the components you would normally see. In real components, the logic tends to be more complicated because each individual task is divided into different lifecycle functions, which can cause difficulties. For example, when you unmount components, you may forget to clean resources, which makes it difficult to find problems in your code.

Confusing Class

The third pit is Class. Understanding classes in JavaScript can be tricky, and in order to be able to use state and lifecycle, we require you to use the class component to do that.

If you’ve ever taken a function component, turned it into a class component, and added some state, you know that this process requires a lot of boilerplate, but it’s only used to define a class component. Most beginners and many experienced developers have also complained to us that the binding and transformation work in classes can be quite confusing. We need to pay attention to this problem.

Also, we often hear that people don’t know exactly when to use a Function component, in part because they worry about converting it to a Class component sooner or later. So you might be confused: I’m not sure I should be doing this right now.

So I say class is hard for humans, but it’s not just hard for humans, I think class is also hard for machines.

If you look at the compressed component file, you can see that all the method names are uncompressed. And if you have a method that’s not being used at all, it’s not being eliminated. This is because it is difficult to determine at compile time exactly whether a method is being used.

We also found that classes make reliable hot loading difficult. Finally, when we designed an optimized compiler prototype to improve React component performance, we found that some of the class component patterns made compiler optimization more difficult.

conclusion

So, we now have three problems: logical reuse, large components, and classes. The problem of logic reuse leads to a lot of “packaging hell.” The reason for the large components is because the logic is spread out over different life cycles. And the confusing class is a problem for both humans and machines.

We think we have a solution that solves all three of these problems. We particularly want to share this with you. Let me bring you Dan Abramov for the rest of our talk.

portal

  • The most important React official documents: Introducing Hooks
  • React Today and Tomorrow (Picture version) – Part one
  • 【React Conf 2018】React Today and Tomorrow
  • React Today And Tomorrow Part I — Sophie’s Keynote
  • React Today And Tomorrow Part II — Dan’s Keynote
  • Dan: Making Sense of React Hooks
  • [原 文] Understand React Hooks
  • React Hooks in 30 minutes

React Conf 2018 — React Today and Tomorrow PART I React Today and Tomorrow PART I Dan Abramov, our Demo Boy, is in the process of translating the React Hooks speech. If you are interested, please contact me to translate it, so that more people can see the React Conf 2018 highlights faster.