High Order Components (HOC)

A High-Order Component (HOC) in React is a function that takes a component and returns a new component with additional props or behaviors. HOCs are a way to reuse component logic across multiple components.

High-Order Function (HOF)

A High-Order Function in programming is a function that either takes one or more functions as arguments or returns a function. It's a pattern not specific to JavaScript or TypeScript but common in functional programming languages.

Reduced Need for HOCs

React Hooks

After the introduction of React Hooks in version 16.8, there has been a noticeable shift in how developers manage state and lifecycle methods in functional components, which previously were only possible in class components. This shift has implications for the usage of Higher-Order Components (HOCs) and their place in modern React development.

State and Lifecycle in Functional Components: With Hooks, you can use state and lifecycle features in functional components without converting them to class components. This reduces the need for HOCs that were primarily used to add stateful logic to functional components.
Custom Hooks: Custom Hooks allow developers to extract component logic into reusable functions, which can be a more straightforward and cleaner way to share logic across components than HOCs. For example, logic that might have been shared using an HOC can now be encapsulated in a custom Hook.
Simplification: Hooks can lead to simpler code compared to HOCs. They avoid the React component tree's "wrapper hell" issue, where multiple HOCs wrap a component, leading to deeply nested component trees and potentially confusing prop forwarding.

Situations Where HOCs Might Still Be Used

Codebase Compatibility: In large codebases, especially those developed before the introduction of Hooks, HOCs might still be prevalent. Refactoring all instances to use Hooks could be impractical or unnecessary if the existing HOCs work well.
Third-Party Libraries: Some third-party libraries might use HOCs to provide their functionality, and developers using these libraries will continue to work with HOCs alongside Hooks.
Complex Prop Manipulation: In cases where a component needs complex manipulation or augmentation of props before being passed down, HOCs can still be an effective pattern. Although custom Hooks can also manage complex logic, HOCs might be preferred for specific patterns of prop manipulation or when dealing with Higher-Order Components provided by libraries.

When HOC were used

Cross-Cutting Concerns: They are ideal for handling cross-cutting concerns like data fetching, permission checks, logging, and more. By encapsulating these concerns in HOCs, the core components can remain focused on presenting the UI.
Conditional Rendering: HOCs can control the rendering of components based on certain conditions, such as feature flags, user permissions, or the presence of data.
Props Manipulation: They can manipulate props before passing them down to the wrapped component, allowing for the injection of new props or modification of existing ones.
State Abstraction and Management: Before Hooks, HOCs were a common way to abstract and manage stateful logic and lifecycle methods, especially for functional components that lacked their own state or lifecycle methods.

Naming conventions

In React, naming conventions for Higher-Order Components (HOCs) play a crucial role in maintaining readable and maintainable codebases. Here are some typical naming conventions for HOCs that can help in identifying and understanding the purpose and functionality of an HOC at a glance:

Prefix with “with”

The most common naming convention for HOCs is to prefix the name with “with”. This prefix indicates that the component is being enhanced or wrapped with additional functionalities or data. For example:

withUserData: Enhances the component with user data.
withLoadingIndicator: Adds a loading indicator feature to the component.
withErrorHandler: Provides error handling capabilities to the component.

This naming pattern is descriptive and immediately tells the developer that the component is being "decorated" or "enhanced" with certain capabilities.

CamelCase Naming

Use CamelCase for HOC names, starting with a lowercase if it's a function and with an uppercase if it directly returns a component. This follows the general JavaScript naming conventions for functions and components:

Correct: withUserData(Component)
Incorrect: with_user_data(Component)

Describe the Enhancement

The name should describe what the HOC does or what it provides to the wrapped component. This makes the code self-documenting to an extent:

withFormValidation: Clearly indicates that validation logic is added to the form component.
withRouter: Indicates that routing-related props are provided to the component.

Reflect the Propagation of Props

If your HOC injects specific props into the wrapped component, it can be helpful to reflect this in the name:

withStyleProps: Suggests that style-related props are added to the component.
withNavigationProps: Implies that navigation-related props are provided.

Consider the Context of Use

When naming HOCs, consider the context in which they will be used. If an HOC is specific to a certain feature or part of your application, include that in the name:

withUserProfileData: Indicates that the HOC is meant for user profile components and enhances them with user data.

Avoiding Naming Collisions

Be mindful of potential naming collisions with existing React or library functionalities. For example, naming an HOC withRef could be confusing alongside React's forwardRef.

Principles that Apply

Open/Closed Principle: Objects or components should be open for extension but closed for modification. Both HOCs and decorators adhere to this principle by allowing extensions without altering the original code.
Single Responsibility Principle: By using HOCs or decorators, you can ensure that each component or class is responsible for a single aspect of functionality. This leads to cleaner, more maintainable code.

Caveats

Complexity: Overusing HOCs or decorators can lead to a complicated hierarchy of wrapped components or decorated classes, making the code harder to understand and maintain.
Props pollution: In the case of HOCs, there's a risk of props pollution where the HOC might pass unnecessary props to the wrapped component, leading to potential conflicts or undesired behavior.
TypeScript Types Complexity: When using TypeScript, typing components that are wrapped with multiple HOCs or classes that are decorated multiple times can become complex and difficult to manage.
Testing: Testing components or classes that use HOCs or decorators can be more challenging, as you might need to consider the behavior added by the HOC or decorator.
Loss of Static Methods: When you wrap a React component with an HOC, the wrapped component loses any static methods it may have. This issue can be mitigated by manually copying methods to the wrapped component, but it's an extra step that's easy to overlook.

Code Example: `withDataFetching`

HOC
WrappedComponent
EnhancedComponent = HoC(WrappedComponent)

Here, withDataFetching is a HOC that takes a URL and a component, fetches the data, and passes it down as a prop to the WrappedComponent.

withDataFetching.tsx
// HOC to handle data fetching
function withDataFetching<T>(url: string, WrappedComponent: React.FC<T>) {
  return (props: T) => {
    const [data, setData] = React.useState<any>(null);
    const [loading, setLoading] = React.useState<boolean>(true);

    React.useEffect(() => {
      fetch(url)
        .then((response) => response.json())
        .then((data) => {
          setData(data);
          setLoading(false);
        });
    }, [url]);

    if (loading) {
      return <div>Loading...</div>;
    }

    return <WrappedComponent {...props} data={data} />;
  };
}

MyComponent.tsx
type MyComponentProps = {
  data: any;
};

const MyComponent: React.FC<MyComponentProps> = ({ data }) => {
  return <div>{JSON.stringify(data, null, 2)}</div>;
};

EnhancedComponent.tsx
const EnhancedComponent = withDataFetching<MyComponentProps>(
  "https://api.example.com/data",
  MyComponent
);

Code Example: `withLogger`

This example is using TypeScript, it wants to show how to create a with function for an already existing component (in this case Logger).

withLogger.tsx
import React, { useEffect } from "react";

interface Props<P> {
  WrappedComponent: React.ComponentType<P>;
  props: P;
}

function Logger<P extends object>({ WrappedComponent, props }: Props<P>) {
  useEffect(() => {
    console.log("Component has mounted:", WrappedComponent.name);
    return () => {
      console.log("Component is unmounting:", WrappedComponent.name);
    };
  }, []);

  return <WrappedComponent {...props} />;
}

const withLogger = <P extends object>(
  WrappedComponent: React.ComponentType<P>
) => {
  return (props: P) => (
    <Logger WrappedComponent={WrappedComponent} props={props} />
  );
};

Reduced Need for HOCs​

Situations Where HOCs Might Still Be Used​

When HOC were used​

Naming conventions​

Prefix with “with”​

CamelCase Naming​

Describe the Enhancement​

Reflect the Propagation of Props​

Consider the Context of Use​

Avoiding Naming Collisions​

Principles that Apply​

Caveats​

Code Example: withDataFetching​

Code Example: withLogger​