DEV Community: Akbar Julian Khatibi

Understanding Liskov Substitution Principle (LSP) in TypeScript and React

Akbar Julian Khatibi — Thu, 27 Jul 2023 21:03:47 +0000

Welcome to another article in the series where we demystify the SOLID principles. Today we'll focus on the Liskov Substitution Principle (LSP), an essential part of writing maintainable, robust code in object-oriented programming.

What is Liskov Substitution Principle?

The Liskov Substitution Principle, named after Barbara Liskov, states that objects in a program should be replaceable with instances of their subtypes without altering the correctness of the program.

In simpler terms, it means that a class should be able to reference a base or derived class without affecting its behavior.

Why is LSP important?

When properly implemented, the Liskov Substitution Principle promotes code reusability and enhances the robustness of the software system. LSP reduces the likelihood of bugs and makes your code easier to understand and maintain.

Liskov Substitution Principle in TypeScript

Let's start with a simple example in TypeScript to illustrate the Liskov Substitution Principle:

class Bird {
    fly() {
        console.log('The bird is flying');
    }
}

class Duck extends Bird {}

const makeBirdFly = (bird: Bird) => {
    bird.fly();
}

makeBirdFly(new Bird()); // Output: The bird is flying
makeBirdFly(new Duck()); // Output: The bird is flying

In this example, we have a Bird class and a Duck class that extends Bird. The makeBirdFly function takes a Bird instance as a parameter and invokes the fly method. As per the LSP, you can replace the Bird instance with a Duck instance without affecting the correctness of the makeBirdFly function.

Applying LSP in React

Now, let's consider a scenario where the Liskov Substitution Principle is violated: We can create a Clickable type that includes an onClick prop:

type ClickableProps = {
  onClick: () => void;
};

const Button: React.FC<ClickableProps> = ({ onClick }) => {
  return <button onClick={onClick}>Button</button>;
};

// Label doesn't have an onClick prop, because it's not meant to be clickable
const Label: React.FC = () => {
  return <label>Label</label>;
};

Now, we might have some logic that requires handling a click event on a component:

type ClickHandler = (components: React.FC<ClickableProps>[]) => void;

const handleClick: ClickHandler = (components) => {
  components.forEach((Component) => {
    // We'll render the component into a "virtual DOM" to trigger the onClick
    const { onClick } = render(<Component />);
    onClick();
  });
};

This would work fine with Button, but if we try to use Label in this way, TypeScript won't compile because Label doesn't have an onClick prop. This demonstrates the Liskov Substitution Principle: Label cannot be used in place of Button because it doesn't fulfil the contract of having an onClick handler.

We've prevented the issue at compile-time, thanks to TypeScript's type system. This prevents us from running into a runtime error where our function tries to call onClick on a Label.

Note: We're using a render function to "virtually" trigger the onClick in this contrived example. In a real-world scenario, you would more likely pass these components around, include them in JSX, and let the user interact with them to trigger any click handlers.

Let's consider another example of a base Button component:

class Button extends React.Component {
  onClick() {
    console.log('Button clicked');
  }

  render() {
    return <button onClick={this.onClick}>Button</button>
  }
}

Now, if we were to create a SubmitButton that extends Button:

class SubmitButton extends Button {
  onClick() {
    console.log('Submitting...');
    super.onClick();
  }
}

According to LSP, any instance where Button is used, SubmitButton should also be able to be used without issues:

const App = () => {
  return (
    <div>
      <Button />
      <SubmitButton />
    </div>
  );
}

Applying LSP in React with Functional Components

Let's consider the base Button component:

import React from 'react';

const Button = ({ onClick, children }) => {
  return (
    <button onClick={onClick}>
      {children}
    </button>
  );
};

export default Button;

This Button component is a simple functional component that receives an onClick callback and children as props, and renders a button.

Now, we'll create a SubmitButton that extends Button in behavior:

import React from 'react';
import Button from './Button';

const SubmitButton = ({ onClick, children }) => {
  const handleClick = () => {
    console.log('Submitting...');
    onClick && onClick();
  };

  return (
    <Button onClick={handleClick}>
      {children}
    </Button>
  );
};

export default SubmitButton;

In this SubmitButton, we have an additional console.log in the handleClick function which will run before any other onClick behavior passed to the SubmitButton.

According to LSP, any place where Button is used, SubmitButton should also be able to be used without causing any issues:

import React from 'react';
import Button from './Button';
import SubmitButton from './SubmitButton';

const App = () => {
  const handleClick = () => {
    console.log('Button clicked');
  };

  return (
    <div>
      <Button onClick={handleClick}>Button</Button>
      <SubmitButton onClick={handleClick}>SubmitButton</SubmitButton>
    </div>
  );
};

export default App;

Here, both Button and SubmitButton are used interchangeably, and SubmitButton performs some additional behavior before running the passed onClick behavior, following the Liskov Substitution Principle.

Flaws

The Liskov Substitution Principle (LSP) is a useful guideline in object-oriented programming that helps ensure that a subclass can replace its superclass without causing incorrect behavior or errors. However, like all principles, it's not without its limitations or criticisms. Here are some of the potential issues:

1. Overly Restrictive: LSP can be seen as too restrictive, especially in dynamic languages or those with more flexible type systems. Sometimes, certain subclasses inherently have different behaviors or properties that make them incompatible with the superclass, even if they share a majority of their characteristics. Strict adherence to LSP can limit the design of such classes.

2. Misinterpretation and Over-Engineering: LSP is often misunderstood, and a strict interpretation can lead to over-engineering. Developers might be tempted to write more complex code just to fulfill the LSP when simpler, more straightforward code could solve the problem more efficiently.

3. Doesn't Fully Solve Inheritance Problems: Even with LSP, problems with inheritance can still occur. For instance, a subclass might need only part of the superclass's functionality, or it might require a different implementation that doesn't fit neatly into the superclass's method signatures.

Consider an application that has a Button component with a click handler. Now, you want to add a DisabledButton that looks the same as Button, but doesn't respond to clicks.

interface ButtonProps {
  onClick: () => void;
}

const Button: React.FC<ButtonProps> = ({ onClick }) => {
  return <button onClick={onClick}>Click me</button>;
};

const DisabledButton: React.FC<ButtonProps> = ({ onClick }) => {
  return <button disabled onClick={onClick}>Can't click me</button>;
};

// Using the components
<Button onClick={() => console.log('Button clicked!')} />
<DisabledButton onClick={() => console.log('Disabled button clicked!')} />

This is where it gets tricky with the Liskov Substitution Principle. According to LSP, a subclass should be substitutable for its superclass without causing any issues. In this case, even though DisabledButton and Button share the same interface (ButtonProps), they behave differently. If you were to replace Button with DisabledButton in your code, the onClick prop wouldn't function as expected, which violates the LSP.

Wrapping Up

The Liskov Substitution Principle is a powerful principle that helps us to write more robust and maintainable code. By adhering to this principle, we ensure that our codebase stays flexible and less prone to bugs.

Remember, SOLID principles are guidelines, not hard rules. There will be times when following these principles might not be practical. However, understanding these principles can guide you towards writing better code.

Understanding the Open-Closed Principle in TypeScript and React

Akbar Julian Khatibi — Mon, 17 Jul 2023 19:25:15 +0000

The Open-Closed Principle (OCP) is one of the five principles of SOLID that guides developers in creating maintainable and scalable code. According to the principle, software entities such as classes, modules, and functions should be open for extension but closed for modification. This principle minimizes the risk of introducing bugs or breaking existing functionality when adding new features. Although SOLID was formulated for object-oriented languages, its principles, including OCP, can be applied to other paradigms such as TypeScript and React.

In TypeScript, the Open-Closed Principle can be achieved using interfaces and class inheritance. An interface defines a set of rules that classes can implement, allowing them to be open for extension. The classes can be used interchangeably in the program, keeping the other parts of the program closed for modification.

For instance, let's consider a geometry program that calculates the area of different shapes. In the example below, the getArea function needs modification to support new shapes, which violates the Open-Closed Principle:

function getArea(shape: { kind: string, length: number }) {
 if (shape.kind === 'square') {
 return shape.length * shape.length;
 }
}

A better approach would be to create a Shape interface that each shape can implement:

interface Shape {
 area: () => number;
}

class Square implements Shape {
 constructor(public length: number) {}
 area() {
 return this.length ** 2;
 }
}

With this approach, each shape defines its area method, and the getArea function is not required. New shapes can be added without modifying existing code, adhering to the Open-Closed Principle.

A Note About Typescript

Even though TypeScript is primarily for type checking and doesn't directly impact the runtime behavior of the code, it can still catch potential bugs at compile time rather than at runtime.

Moreover, interfaces can guide the design of your code by specifying contracts that classes must adhere to. In this case, the Shape interface is saying that any shape must have an area method that returns a number. This encourages a consistent design where different shape classes can be treated in a uniform way.

So, while TypeScript interfaces don't have a direct impact on the resulting JavaScript code, they have a significant impact on the TypeScript code's correctness, maintainability, and design.

Examples In React
In React, the Open-Closed Principle can be applied by creating components that accept props and children. This way, the components can be extended by passing different props and children without modifying the component's code.

For example, a List component can accept an array of items and a function to render each item (renderItem), making the component highly reusable and extendable:

function List({ items, renderItem }) {
 return (
 <ul>
 {items.map(renderItem)}
 </ul>
 );
}

With this component, we can create a list of strings, a list of numbers, a list of complex objects, etc., by passing a different renderItem function and items array. We can extend the List component's functionality without modifying its code, keeping with the Open-Closed Principle.

Remember, adhering to the Open-Closed Principle can help you create robust and maintainable code in TypeScript and React. Happy coding!

Understanding React and React Native Through the Principle of Single Responsibility

Akbar Julian Khatibi — Thu, 18 May 2023 20:24:38 +0000

When building a complex web or mobile application, it's critical to consider the underlying principles that can guide the architecture and design of your app. One such fundamental principle, rooted deeply in computer science, is the Single Responsibility Principle (SRP). This principle is an integral part of SOLID principles of software design and applies directly to how we can effectively use React and React Native in our projects.

What is the Single Responsibility Principle?
The Single Responsibility Principle states that a class should have only one reason to change. This principle, introduced by Robert C. Martin, commonly known as Uncle Bob, emphasizes that a class or a module should focus on a single task.

While SRP was originally coined for class-based object-oriented programming, the principle is applicable in a broader sense, especially in the world of JavaScript and, more specifically, React and React Native.

Applying SRP to React and React Native
React and React Native are JavaScript libraries used for building user interfaces. React is mainly used for web development, while React Native is used for mobile application development.

When using these libraries, SRP can be effectively applied through the use of components. A component in React or React Native should ideally be responsible for rendering a specific part of the UI and handling the interactions within that part. By making each component responsible for a single task, we bring the benefits of SRP to our projects.

Benefits of Using SRP in React and React Native

Increased Maintainability
When components are responsible for a single task, they become more straightforward and easier to maintain. If a feature needs to be updated or a bug needs to be fixed, developers can quickly locate the relevant component and make the necessary changes without affecting the rest of the application.
Enhanced Testability
Single responsibility components simplify unit testing. Each component can be tested in isolation, ensuring that it performs its primary function correctly.
Reusability
SRP allows components to be generic and therefore more reusable. By ensuring that a component has a single responsibility, it can often be used across different parts of an application or even across different projects.
Simplified Reasoning
Components with a single responsibility are easier to understand. Developers can look at a component and quickly understand what it does, which simplifies both development and code reviews.

An Example
Consider a profile page on a social media app developed using React Native. Instead of creating one large component responsible for rendering the entire page, you could break down the page into smaller components, each with its own responsibility. You might have one component for the profile picture, another for the user's basic info, one for the list of posts, and so on. Each of these components would have a single responsibility, making them easier to develop, test, and maintain.

Balancing SRP: Potential Drawbacks
While the Single Responsibility Principle brings numerous benefits, like any principle, it should not be applied blindly. There are some potential drawbacks that developers need to be aware of when trying to adhere strictly to SRP:

1. Over-Engineering
The most common pitfall when applying SRP is over-engineering. If taken to an extreme, every minor function of an application might end up in a separate component. This can lead to an unnecessary proliferation of components, making the codebase harder to navigate and understand.

2. Increased Complexity
While SRP can simplify individual components, it may also inadvertently increase the overall complexity of your application. Managing data flow between numerous smaller components can be more challenging than in a system with fewer, larger components.

3. Performance Overhead
Creating too many components can also lead to performance overhead. Every React component comes with a certain amount of overhead for React's virtual DOM diffing algorithm, and creating too many components can slow down the rendering process.

Striking a Balance
The key to effectively using the Single Responsibility Principle in React and React Native is balance. It's essential to consider the complexity of the component and the likelihood of change. Not every piece of logic needs to be its own component; sometimes, it's better to group related logic together for the sake of readability and performance.

The Single Responsibility Principle is a tool, not a rule. Use it to guide your decisions and inform your architecture, but don't let it dictate your every move. Each project is unique and requires a thoughtful approach to strike the right balance between component simplicity, maintainability, performance, and overall complexity.

Remember, the ultimate goal of any principle or pattern is to improve the quality of the code and the productivity of the developers. If strict adherence to a principle is counterproductive, it may be necessary to reconsider its application.

By understanding the potential pitfalls and benefits of the Single Responsibility Principle, developers can make better design decisions, creating applications that are both robust and manageable.

Conclusion
The Single Responsibility Principle, while simple, is incredibly powerful. It can be effectively applied to improve the design and architecture of applications built with React or React Native. By understanding and using this principle, we can create applications that are more maintainable, testable, reusable, and easier to reason about.

So next time you're working on a React or React Native project, consider the Single Responsibility Principle. It just might make your work easier and your code better.

Building Large-Scale React Native Applications: A Modular Approach

Akbar Julian Khatibi — Fri, 12 May 2023 02:44:41 +0000

In the world of React Native application development, creating small applications is straightforward. But as the project grows, managing it can become quite a challenge. In this article, we'll discuss a modular approach for building large-scale React Native applications.

The Need for Modularization

As a React Native application grows, so does its complexity. Components become interconnected, state management gets complicated, and before you know it, your codebase turns into a tangled mess. This is where the concept of modularization comes in.

Modularization involves breaking down your application into separate, independent modules. Each module is responsible for a specific feature or functionality of your application and operates independently of the others. This approach offers several benefits:

Easier Code Management: By breaking down your application into smaller parts, the codebase becomes easier to manage and understand.
Reusability: Modules can be reused across different parts of the application or even in different projects.
Parallel Development: Different teams can work on different modules simultaneously, which can speed up the development process.

Implementing a Modular Structure

1. Splitting Up Your Application
The first step in creating a modular React Native application is to decide how to split up your application. A good approach is to divide your application based on its features. For example, if you're building a social media app, you could have separate modules for user authentication, posting, commenting, and so on.

2. Creating a Directory Structure
For each module, create a separate directory in your project. A typical module directory might look something like this:

/my-module
  /components
  /services
  /state
  index.js

In this structure:

components directory holds all the React components related to that module.
services directory contains any services that the module might need, such as API calls.
state directory includes all state management code (like Redux or MobX) for that module.
index.js is the entry point for the module.

3. Implementing Navigation
In a modular structure, each module should define its own navigation. React Navigation, a popular navigation library for React Native, supports this perfectly. Each module can export its own navigator, which can then be imported into the main navigator.

4. Managing State
For state management, consider using Redux or MobX. Both of these libraries support a modular structure. Each module can define its own actions and reducers (in Redux) or observables and actions (in MobX), which can then be combined at the application level.

Pitfalls to Avoid
While modularization can greatly improve your development process, there are a few common pitfalls to avoid:

- Over-Modularization: While it's important to separate concerns, creating too many modules can make your codebase hard to navigate. Aim for a balance between separation of concerns and simplicity.
- Tightly Coupled Modules: Modules should be as independent as possible. If you find that one module is heavily dependent on another, consider whether they should actually be a single module.

Conclusion

Building large-scale applications is a significant undertaking, but with a modular approach, the process can become much more manageable. By breaking your application down into smaller, independent parts, you can create a codebase that is easier to understand, more reusable, and more conducive to parallel development. It's a win-win for everyone involved!