To clarify, React Hooks are a proposed new feature that is expected to ship with React 16.7.0. / React refers to ReactJS. React is called/for short

To understand React Hooks, let’s start with HOC and FaCC/Render Props

HOC(higher-order Components) React higher-order Components

If we have a state that needs to be shared, it needs to be passed between multiple components. What would we do? Or, what do we choose to do when multiple components have common parts?

Such as:

// ComponentA
import React, { Component } from "react";

export default class ComponentA extends Component {
  state = { toggle: false };
  click = (a)= > {
    this.setState({ toggle:!this.state.toggle });
  };

  render() {
    const { toggle } = this.state;
    return (
      <div className="App">
        <button onClick={this.click}>Toggle Name</button>
        {toggle && <div>ComponentA</div>}
      </div>); }}Copy the code

So let’s take an extreme example here, let’s have ComponentB do the same thing as A

// ComponentB
export default class ComponentB extends Component {
  state = { toggle: false };
  click = (a)= > {
    this.setState({ toggle:!this.state.toggle });
  };

  render() {
    const { toggle } = this.state;
    return (
      <div className="App">
        <button onClick={this.click}>Toggle Name</button>
        {toggle && <div>ComponentB</div>}
      </div>); }}Copy the code

You can see that there is a lot of duplication in the code, only the text display is different. That’s where HOC comes in.

After using HOC, become

// ComponentA
import React, { Component } from "react";
import HOC from "./HOC";

class ComponentA extends Component {
  render() {
    return <div>ComponentA</div>; }}export default HOC(ComponentA);
Copy the code

The same goes for ComponentB.

HOC is written to take the common part and receive a Component for rendering.

const HOC = WrapperComponent= >
  class HOC extends Component {
    state = { toggle: false };
    click = (a)= > {
      this.setState({ toggle:!this.state.toggle });
    };

    render() {
      const { toggle } = this.state;
      return (
        <div className="App">
          <button onClick={this.click}>Toggle Name</button>
          {toggle && <WrapperComponent />}
        </div>); }};export default HOC;
Copy the code

As you can see, the common parts are pulled out and the code looks simpler and more comfortable. Each component only needs to focus on its own internal state, leaving the public and shared state to HOC. No matter how many similar components you add, you don’t have to write a lot of duplicate code.

FaCC(Function as Child Component)

The mechanism is similar to HOC, except that it uses a react props called Children

//ComponentA
export default class ComponentA extends Component {
  render() {
    return <FaCC>{toggle => toggle && <div>ComponentA</div>}</FaCC>; }}Copy the code
//FACC
export default class FaCC extends Component {
  state = { toggle: false };
  click = (a)= > {
    this.setState({ toggle:!this.state.toggle });
  };

  render() {
    const { toggle } = this.state;
    return (
      <div className="App">
        <button onClick={this.click}>Toggle Name</button>
        {this.props.children(toggle)}
      </div>); }}Copy the code

Render Props use the same method, but with a different property instead of children

So what else can HOC do?

As we have seen from the above behavior, they can share many parts of the code. If you think a little further, you can see that in complex business logic, if you send the same API request into the Haul, you should not send a request in each individual component. Because they share the same state, this can cause a waste of resources. Let’s change some of HOC’s code, for example:

const HOC = WrapperComponent= >
  class HOC extends Component {
    state = { toggle: false.data: {}}; fetchData =(a)= > {
      fetch("/api", params).then(response= > {
        const { data } = data;
        this.setState(data);
      });
    };
    componentDidMount(){
        this.fetchData();
    }

    render() {
   /*......*/
  };

export default HOC;
Copy the code

React Hooks

Using Effect in Hooks allows us to use the same part of the lifecycle as Component. I’ll cover the ReactHooks in more detail in another article. What I want to do here is compare React Hooks, HOC, FACC.

So what do React Hooks do if they want to do this?

// Hooks
import { useState, useEffect } from "react";

const useHooks = (a)= > {
  const [data, setData] = useState(null);

  const fetchData = (a)= > {
    fetch("/api", params).then(response= > {
      const { data } = data;
      setData(data);
    });
  };

// Effect equals componentDidMount
  useEffect((a)= > {
    fetchData();
  });

  return data;
};

export default useHooks;
Copy the code

This is all we need to do when we need the common data in the Component

  // This line is the method that calls data
    const data = Hooks();
    return <div>{data}</div>;
Copy the code

The advantages of ReactHooks?

ReactHooks do not require complex DOM structures.

Using HOC eliminates the problem of repeated applications. However, when we open the React Dev Tool, we’ll see that our DOM structure is also more complex. from

become

And then to

More importantly, I find ReactHooks easier to write, understand, and read.

I think it’s not hard to come to this conclusion by comparing the above code.

Imagine the code complexity associated with extensive use of HOC in a large project.

Why do I think React is the future of the front-end

As I described earlier, both HOC and FACC/Render Props have their own technical difficulties to get started with and understand. But React Hooks fixed those problems.

Someone must disagree, and it would be irresponsible to guess why

  1. The industry itself needs to have a certain technical threshold, the difficulty of writing and understanding is the problem of the individual’s own learning ability and study degree, the framework should not pay for this.
  2. React hooks themselves violate some JS conventions and trends in terms of writing implementations, such as pure functions.

My answer is as follows

  1. The technical barrier is good, but I think technology is there to change lives, not to put some people to work. Just like there are professional car drivers and there are ordinary road drivers. As professionals engaged in this industry, we should study and understand a technology. But if a colleague on the back end, or a small start-up team, needs to build one of these things. I think the simplicity of the technology and the ease of implementation should be an attraction for them.
  2. I agree that many libraries have “weird” ways of writing in one way or another in order to achieve some neat functionality. But sometimes there are trade-offs.

I don’t think there are front-end frameworks that are aware of simple ways to handle increasingly complex businesses, which Angular and Vue have yet to do. Angular is complete, but the learning curve is steep. Vue is facing an entire library rewrite. React handles complex business in a simple way, and the ecosystem of third-party libraries is huge.

So, I’m bullish on it.