Do Function Components Equal Functional Programming?

React developers are already familiar with the fact that React has two component types:

• Class Component
• Function Component

Considering the mention of "class" and "function", questions naturally arise:

• Are class components related to object-oriented programming (OOP)?
• Are functional components related to Functional Programming (FP)?

After all, if class components are related to OOP, then OOP principles (inheritance, encapsulation, polymorphism, etc.) can guide the development of class-based components. Similarly, FP principles can affect functional components. In other words, we can directly apply the best practices of these programming paradigms to React projects.

So, what is the relationship between functional components and functional programming? This article will delve into this topic.

Programming Paradigms and DSL

First of all, we should make it clear that the framework syntax is essentially a DSL (Domain Specific Language) that is customized for development in a specific domain.

For example, React is a DSL for building views. Although different platforms use different frameworks to build views, for example:

• Web side: ReactDOM
• Mini Program: Taro
• Native development: ByteDance’s internal framework React Lynx

These frameworks usually follow the same DSL (React syntax). This DSL is not tied to any particular programming paradigm, but should be viewed as a set of language features that are well suited for view development.

So, as part of the React DSL:

• Function components can embody OOP principles.
• Class components can reflect FP principles.

As long as these principles are beneficial to view development, they can be integrated into the DSL.

For example, consider the following functional component Header consisting of WelcomeMessage and LogoutButton, which demonstrates the principle of composition over inheritance in OOP:

function Header(props) {
  return (
    <div>
      <WelcomeMessage name={props.name} />
      <LogoutButton onClick={props.onLogout} />
    </div>
  );
}

Similarly, consider the class component Cpn, where the state count is updated not by mutation (this.state.count), but by calling this.setState with immutable data:

class Cpn extends React.Component {
  // ...
  onClick() {
    const count = this.state.count;
    this.setState({ count: count + 1 });
  }
  render() {
    // ...
  }
}

Using immutable data reflects the principles of FP.

Therefore, when exploring any React feature, we should consider the following three steps:

1. What is the core development philosophy of React?
2. What ideas from various programming paradigms were used to implement this idea?
3. How can these ideas be applied in React?

By applying this thought process to the relationship between functional components and functional programming, we find:

• Function components are the result of implementation (step 3).
• Functional programming is a programming paradigm (step 2).

This defines the relationship between them: Functional components are the product of implementing multiple programming paradigms (mainly OOP and FP) in React, borrowing some ideas from FP in the process.

Functional components should not be viewed solely as the embodiment of functional programming in React.

The evolution of functional components

Let’s explore the evolution of functional components using the three-step thought process mentioned earlier. React's development philosophy is best expressed by the following formula:

function Header(props) {
  return (
    <div>
      <WelcomeMessage name={props.name} />
      <LogoutButton onClick={props.onLogout} />
    </div>
  );
}

In order to realize this concept, two key elements are needed:

• Data Snapshot
• Function mapping

Here, the immutable data from FP is more suitable as the carrier of data snapshot. This is why state in React is immutable - the essence of state is a snapshot.

There are no specific requirements for the carrier of function mapping. In React, every update triggers a re-rendering, and the rendering process itself is a function mapping process. The input is props and state, and the output is JSX.

In contrast, Vue components are more in line with OOP principles. Consider this Vue App component:

class Cpn extends React.Component {
  // ...
  onClick() {
    const count = this.state.count;
    this.setState({ count: count + 1 });
  }
  render() {
    // ...
  }
}

The component's setup method is only executed once during initialization. Subsequent update operations operate on the same data within the closure, which corresponds to the concept of instances in OOP.

Since React does not impose special requirements on the carrier of function mapping, both class components and function components are viable options.

Why did function components replace class components?

Many people believe that improving the reusability of logic through hooks is the main reason why functional components are superior to class components. However, the decorator-based class development model, especially when combined with TypeScript, has proven to be an effective method of logic reuse.

The real reason is that function components can better implement the concept of UI = fn(snapshot).

As mentioned before, the snapshot in the formula represents a snapshot of the state, which in React includes:

• state
• props
• context

For a given component, the formula UI = fn(snapshot) ensures that the same snapshot produces the same output (JSX). However, state updates may also trigger side effects, such as data fetching or DOM manipulation.

In class components, these side effect logics are scattered in various life cycle methods, making React difficult to control. But in function component:

• Side effects are limited to useEffect. React ensures that side effects from previous renders are cleaned up (via useEffect's return value) before applying new side effects.
The propagation of
• ref is restricted through mechanisms such as forwardRef, limiting its potential impact.
• Data fetch side effects are managed by Suspense as follows:

<code>UI = fn(snapshot);</code>

Usage:

const App = {
  setup(initialProps) {
    const count = reactive({ count: 0 });
    const add = () => { count.value++; };
    return { count, add };
  },
  template: "...omitted"
};

In short, functional components ensure that side effects remain controllable, providing consistent output for the same snapshot input. This is consistent with the concept of pure functions in FP, which is why functional components have become a mainstream choice in React.

Conclusion

Function components are not a direct implementation of functional programming in React, but the most appropriate carrier to implement the core concept of React UI = fn(snapshot). React integrates excellent ideas from various programming paradigms, of which FP has the greatest influence. Ultimately, every design choice serves the overall idea.

---

We at Leapcell, are your first choice for hosting your Node.js projects.

Leapcell is a new generation serverless platform for web hosting, asynchronous tasks and Redis:

Multi-language support

• Develop with Node.js, Python, Go, or Rust.

Deploy unlimited projects for free

• Pay only for what you use – no requests, no fees.

Unparalleled cost-effectiveness

• Pay as you go, no idle fees.
• Example: $25 supports 6.94 million requests with an average response time of 60ms.

Simplified developer experience

• Intuitive UI, easy to set up.
• Fully automated CI/CD pipeline and GitOps integration.
• Real-time metrics and logging for actionable insights.

Easy scalability and high performance

• Auto-scaling to easily handle high concurrency.
• Zero operational overhead - just focus on building.

Learn more in the documentation!

Follow us on X: @LeapcellHQ

---

Read our blog

The above is the detailed content of Do Function Components Equal Functional Programming?. For more information, please follow other related articles on the PHP Chinese website!