DEV Community: fajarriv

Creating User-Friendly Interfaces: Nielsen's 10 Usability Heuristics

fajarriv — Mon, 20 May 2024 00:41:35 +0000

In today's digital world, a user-friendly interface (UI) is no longer a luxury thing, it's a necessity. Whether it's designing a website, a mobile app, or any other interactive product. A well-crafted UI can be the key to turning frustrated users into satisfied users.

This is where Nielsen's 10 Usability Heuristics come in. Created by Jakob Nielsen, a leading expert in web usability, these guidelines help designers create interfaces that are not only functional but also pleasant to use. Whether we are an experienced designer or just starting out, these principles can greatly improve the usability of our designs.

What are Nielsen's Usability Heuristics?

Nielsen's usability heuristics are ten general rules for designing user interfaces. They are not specific instructions but rather broad tips to help identify usability problems. These heuristics provide a basic framework that can be applied to various platforms and devices, ensuring a consistent and effective user experience. Let's explore each of these heuristics and see how they contribute to better UI design.

1. Visibility of System Status

Users should always know what's happening through timely feedback. This means the system should keep users informed about what's going on, providing feedback quickly. For example, a loading indicator lets users know their action is being processed.

2. Match Between System and the Real World

The system should use language and concepts familiar to users, not technical jargon. It should follow real-world conventions, making information appear naturally. For example, using a trash can icon on delete action.

3. User Control and Freedom

Users often make mistakes and need a clear way to exit an unwanted state without a hassle. Support 'undo' action will give users the freedom to decide the actions they intended to do. This principle will helps prevent users from frustration and errors.

4. Consistency and Standards

Users shouldn't have to wonder if different words, situations, or actions mean the same thing. Consistency in design and terminology makes users feel more comfortable and familiar with the interface, reducing the learning curve. For example, we should use the same layout and button styles in different page.

5. Error Prevention

It's better to design in a way that prevents errors from happening in the first place than to rely on good error messages. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they proceed. For example, ask users to confirm their actions before finalizing it.

6. Recognition Rather Than Recall

Minimize the user's memory load by making options and information visible. Users shouldn't have to remember information from one part of the interface to another. Instructions should be visible or easily accessible whenever needed. This principle emphasizes designing interfaces that allow users to recognize options and information rather than recalling them from memory. For example, we provide description of the action and the konselor name that previously selected.

7. Flexibility and Efficiency of Use

Speed up interaction for expert users with shortcuts, without making it harder for beginners. For instance, we should make input fields that can perform shortcuts, such as copy and paste but still make the input field selectable for beginners

8. Aesthetic and Minimalist Design

Interfaces should not have irrelevant or rarely needed information. Every extra piece of information competes with the relevant information, reducing its visibility. A minimalist design approach ensures that only essential elements are present, reducing distractions and helping users focus on what matters.

9. Help Users Recognize, Diagnose, and Recover from Errors

Error messages should be in plain language, clearly indicating the problem and suggesting a solution. This principle is about providing clear and helpful error messages that guide users to fix issues effectively.

10. Help and Documentation

Even though it's best if the system can be used without help, it’s good to provide help and documentation. Such information should be easy to search, focused on the user's tasks, list clear steps, and be concise. Comprehensive and accessible help documentation ensures users can find assistance when needed, improving their overall experience.

By applying Nielsen's 10 Usability Heuristics to our design, we can create interfaces that are more intuitive, efficient, and user-friendly. These principles are timeless and flexible, offering a solid foundation for addressing common usability issues and enhancing the overall user experience.

Creating mocks for testing react code

fajarriv — Sun, 21 Apr 2024 22:16:24 +0000

When dealing with components that fetch data from APIs, writing tests can become really hard due to external dependencies. This is where mocks and stubs come in, providing a controlled environment to isolate and test your component's logic. In this post we will explore what mocks and stubs are, how they differ, and how Mock Service Worker (MSW) simplifies API mocking in Next.js project using Jest and React Testing Library.

Mocks vs Stubs: What’s the Difference?

In testing, both mocks and stubs are types of test doubles - objects that simulate the behavior of real objects. They are used to isolate the code under test from the rest of the system.

Mock: Replicate the entire behavior of an object, including side effects and interactions with other components. Mocks are often used for complex dependencies with intricate behavior. A mock ia an object that pre-programmed with expectations which form a specification of the calls they are expected to receive.
Stub: Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. They typically focus on returning predefined values or performing specific actions without replicating the complete behavior.

Roy Osherove in his book The art of Unit Testing

The easiest way to tell we’re dealing with a stub is to notice that the stub can never fail the test. The asserts the test uses are always against the class under test.

On the other hand, the test will use a mock object to verify whether the test failed or not. [...]

Again, the mock object is the object we use to see if the test failed or not.

Create Stubs and Mocks with jest

For example, I have UbahJadwal component that depend on a custom useJadwalKonselor hooks for displaying some data. This component also use useSearchParams method from next/navigation and a method to displaying toast.

Since we use many external dependencies in the component, all tests will surely fail if we don't create test doubles for all the dependencies.

From the error description, we can see why it fails because of the useSearchParam().get() didn't return anything. To solve this issue we can simply create a stub for the get function.



jest.mock("next/navigation", () => {
  return{
    useSearchParams: jest.fn(() => ({
      get: jest.fn().mockResolvedValue(""),
    }
    ))
  }
})

Now, some of the tests from the test suite have already passed.

The next problem is the component should be populated by data from useJadwalKonselor hooks. What The hooks do is simply fetch data to be displayed inside a Modal. We can mock the implementation of the hooks to return the API response.



jest.mock("../../../../../src/hooks/bkm-1/useJadwalKonselor.ts", () => ({
  useJadwalKonselor: jest.fn().mockImplementation(() => {
    return {
      data: {
        id: "59f30d61-4cc6-4ec3-90c1-c11663217889",
        nama: "Konselor B",
        jadwal_praktik: [
          {
            nama_hari: "Selasa",
            waktu_mulai: "10:00:00",
            waktu_selesai: "16:00:00",
          },
          {
            nama_hari: "Kamis",
            waktu_mulai: "12:00:00",
            waktu_selesai: "15:00:00",
          },
        ],
      },
      isLoading: false,
      error: null,
    }})
}))

We can see the all tests passed now

Mocking API calls

Let's consider we want to mock an API call to fetch some data, what we can do is we mock the global fetch function like this.



    global.fetch = jest.fn(
      () =>
        Promise.resolve({
          json: () =>
            Promise.resolve({ data: [{
          "nama_pasien": "A",
          "is_pagi": true,
          "is_terjadwal": true,
          "skala_prioritas": 10,
          "created_at": "2024-01-01 00:00:00+0000",
          "id_pendaftaran": "00000000-0000-0000-0000-000000000000",
        }]}),
          ok: true,
        }) as Promise<Response>
    )

The above code will do the job. The problems come when we have multiple fetch functions inside one component (fetch with GET and POST/PUT methods).

Mocking with MSW

While mocks are effective, they require modifying the component's internal logic or mocking global functions like fetch. This can become cumbersome for complex components with numerous API interactions. Here's where MSW shines.

MSW is a library that lets you create a mock service worker that intercepts all network requests made from your frontend application. It allows you to define handlers that specify how to respond to specific API calls with predefined data or errors. This approach offers several benefits:

Isolation: Isolates your frontend from external dependencies for reliable and consistent tests.
Flexibility: Easily define various responses for different scenarios without modifying component logic.
Simplicity: Provides a cleaner testing experience compared to manual mocks and stubs.
Network Interception: Captures actual network requests for inspection and debugging.

Here’s a basic example of how to use MSW to mock a GET request:



import { rest } from "msw"
import { setupServer } from "msw/node"
const handlers = [
  rest.get(
    process.env.NEXT_PUBLIC_API_URL_1 +
      "/api/konseling/konselor/59f30d61-4cc6-4ec3-90c1-c11663217889/",
    (req,res,ctx) => {
      return res(ctx.json({
        "id": "59f30d61-4cc6-4ec3-90c1-c11663217889",
        "nama": "Konselor B",
        "no_wa": "0857651920018",
        "jadwal_praktik": [
          {
            "urutan_hari": 1,
            "nama_hari": "Selasa",
            "waktu_mulai": "10:00:00",
            "waktu_selesai": "16:00:00"
          },
          {
            "urutan_hari": 3,
            "nama_hari": "Kamis",
            "waktu_mulai": "12:00:00",
            "waktu_selesai": "15:00:00"
          }
        ],
        "tipe": "Konselor"
      }),ctx.status(200))
    }
  ),
  rest.get(process.env.NEXT_PUBLIC_API_URL_1 +
      "/api/konseling/konselor/2d142202-acbf-4cfd-8ba7-8e02d7857056/",
  (req,res,ctx) => {
    return res(ctx.json({
      "error": "Konselor tidak ditemukan"}
    ),ctx.status(404))}),

  rest.get(process.env.NEXT_PUBLIC_API_URL_1 +
      "/api/konseling/konselor/39a3ee55-8bcb-4bc8-9212-875c92ff4311/",
  (req,res,ctx) => {
    return res(ctx.json({
      "INTERNAL_SERVER_ERROR": "Internal Server Error"}
    ),ctx.status(500))}),
]




const server = setupServer(...handlers)

beforeAll(() => server.listen())
afterEach(() => server.resetHandlers())
afterAll(() => server.close())

describe("useDetailKonselor", () => {
  it("should return detail konselor", async () => {
    const { result } = renderHook(() => useDetailKonselor("59f30d61-4cc6-4ec3-90c1-c11663217889"))

    expect(result.current.isLoading).toBeTruthy()

    await waitFor(() => expect(result.current.isLoading).toBeFalsy())
    expect(result.current.data).toEqual({
      "id": "59f30d61-4cc6-4ec3-90c1-c11663217889",
      "nama": "Konselor B",
      "no_wa": "0857651920018",
      "jadwal_praktik": [
        {
          "urutan_hari": 1,
          "nama_hari": "Selasa",
          "waktu_mulai": "10:00:00",
          "waktu_selesai": "16:00:00"
        },
        {
          "urutan_hari": 3,
          "nama_hari": "Kamis",
          "waktu_mulai": "12:00:00",
          "waktu_selesai": "15:00:00"
        }
      ],
      "tipe": "Konselor"
    })
  })

  it("should return error when konselor not found", async () => {
    const { result } = renderHook(() => useDetailKonselor("2d142202-acbf-4cfd-8ba7-8e02d7857056"))
    await waitFor(() => expect(result.current.error).toBeDefined())

    expect(result.current.error?.message).toEqual("Konselor tidak ditemukan")
  })
})

The Result :

Test-Driven Development (TDD) in frontend code.

fajarriv — Sun, 31 Mar 2024 22:56:41 +0000

Image taken from here.

What is Test-Driven Development(TDD)?

Test-Driven Development (TDD) is a software development approach where developers write tests before writing the actual code. TDD follows a simple and iterative cycle, often referred to as the “red-green-refactor” cycle:

Write a failing test (red): Start by creating a test that describes the desired behavior of a piece of functionality. This test initially fails because the corresponding code doesn’t exist yet.
Write the minimum code (green): Write the minimum amount of code necessary to make the test pass. This code might be incomplete or inefficient at this stage.
Refactor: Once the test passes, refactor the code to improve its quality while ensuring that the tests continue to pass.

TDD: Frontend vs Backend

TDD excels in backend development because the world of backend logic is more predictable. Backend code typically deals with data manipulation, business rules, and API interactions. These tend to be well-defined and less prone to change compared to frontend UI design. TDD's upfront test writing style works well in this stable environment.

Frontend development, on the other hand, is a more fluid world. UI designs can evolve throughout the development process based on user feedback or changing requirements. Tests written for an initial design might need adjustments as things change. Additionally, TDD can make developers focus on functionality over visual design initially. While crucial for a solid foundation, this might feel restrictive for UI-focused developers who want to explore design options freely.

Unit testing

Unit testing is a software development technique where individual units of source code, typically functions, classes, or components, are tested to verify their correctness in isolation. Unit tests are designed to be independent and self-contained, meaning they should not rely on external factors or interact with databases or other external systems.

Writing test cases

Writing effective test cases is crucial for ensuring the quality and reliability of your frontend application. Well-crafted tests help catch bugs early in the development process, prevent regressions, and boost developer confidence when refactoring code.

There are various techniques we can use to write comprehensive test cases such as user story based testing, happy path vs sad path testing, and component behavior-based testing.

Journey of writing unit test

Note: Examples for frontend are written using jest with react-testing-library.

I never tested my frontend code before; I only used to write backend tests. For me, writing a backend unit test is always much easier than writing a frontend unit test because of the predictable logic on the backend.

Here's example of my backend unit test. Writing these tests very straightforward, first we setup the data/state for our input and processing. After that we write test for positive, negative, and edge cases.

My journey of writing unit test in frontend began with reusable components, the building blocks of UIs. Here, the focus was on ensuring the component itself functioned as intended in isolation. So, the main case that we want to test is the correctness of the rendered component.

Next, I tackled testing hooks for fetching data, the functions responsible for retrieving data from external sources. Testing these hooks became crucial to ensure our application displayed accurate data. Here, unit tests allowed me to mock the API responses, simulating different scenarios like successful data retrieval or errors.

Finally, I need to write test for large component/page component. Writing test for this type of components will be tricky. It's because this kind of component depends to other components or hooks. In order to isolate the SUT we need to mock other components/hooks that used inside the SUT.

When writing the test cases, it's easier for me to think based on behaviors of individual UI components rather than thinking of successful and unsuccessful scenarios of components.

For example, i have a button component that will open a modal/dialog that ask confirmation to delete an entity.

The first test case comes up in my mind is to test if my button is rendered properly or not. After that i want to make sure the modal is popped up and rendered correctly too. I repeat this process of thinking when writing the modal behavior test cases.

Code implementation and test results

Things to consider when writing unit tests

There are important considerations to keep in mind when writing effective tests specifically for frontend development such as things that should not be unit-tested.

Target Individual Components: Unit tests should be focused on a single unit of code. This promotes isolation and makes tests easier to understand, maintain, and debug.

Mock External Dependencies: Frontend components often rely on external dependencies like APIs and other components. When unit testing, it's essential to mock these dependencies to prevent them from interfering with your test logic (mock everything outside the Subject Under Test).

Follow the Triple A (Arrange, Act, Assert) Pattern: This is a fundamental best practice for structuring unit tests. It promotes clear separation of concerns and makes tests easier to read and maintain.

Benefit from unit testing

One of the most significant advantages is the safety net it provides for refactoring. Refactoring involves restructuring existing code without changing its overall functionality. This can be essential for improving code readability, reducing complexity, and aligning your codebase with best practices. Unit tests act as a guardrail during this process. By running the test suite after making any code changes, we can ensure that the refactored code still produces the expected results. This catches any unintended regressions early on, preventing bugs from creeping in and saving us debugging headaches down the line.

Unit tests essentially give us the confidence to make changes to your codebase knowing that we won't break existing functionality in the process. This empowers us to experiment with different code structures and optimizations, ultimately leading to a cleaner, more maintainable frontend application.

Leveraging Tools to Enhance Collaborative Efficiency

fajarriv — Wed, 20 Mar 2024 23:15:00 +0000

Working on a team when creating a software is very different from tackling a solo-project. Putting a group of people together doesn't guarantee success. It's super important to work well with others, but teamwork is not just about working alongside each other, it's also about leveraging the right tools to enhance communication and efficiency. Understanding and demonstrating disciplined use of these tools can significantly benefit group work, leading to more streamlined processes and successful outcomes. I'll talk about what my team uses to work together.

Meaningful Commit Messages

Every time a developer pushes code changes to the repository, they include a commit message. This message/note explains what changes were made and why. Writing these notes well is a big help for everyone.

To ensure your commit messages are crystal clear and informative, follow a common standard like the Conventional Commits specification. This specification provides a simple set of guidelines for writing clear and concise commit messages that make it easier for us to understand the code history.

Clear commit messages mean:

Easy Code History: Anyone working on the project, now or in the future, can understand why changes were made.
Better Teamwork: Clear messages explain the "what" and "why" of changes, avoiding confusion and promoting collaboration.
Faster Problem Solving: If something goes wrong, clear messages help pinpoint the exact change that might have caused it.

Sharing Code with Merge Requests

Merge requests in GitLab let us add our own work to the team's project. It's also allowed other team members to review our code, making sure that our code is correct and fits into the target branch.

To minimize bugs, we can add reviewers to our merge request. We should also fill MR description with summary of our changes.

Keeping Track with Jira

Jira helps us to see who's doing what and how the project is going. It's like a big board with all our issue/backlog on it, so we can move things around and stay flexible. Everyone can see their jobs and how the whole project is moving forward.

In Jira, we can add description, priority, child issues/tasks and many other things to the issues/backlog. This feature allows teams to organize and prioritize their work effectively.

Communication using Discord

Discord has become a powerful communication tool that is useful for more than just fun conversation. Discord has a lot of features that enhance communication and collaboration for teams. For example, it offers voice channels for real-time voice conversations, text channels for asynchronous chat, video calls for face-to-face interaction, and screen sharing for live demonstrations or presentations.

Additionally, Discord supports server customization with roles and permissions, bot integrations to automate tasks or add fun activities, and webhooks to connect with other services and tools.

The integration of JIRA and GitLab with Discord allows for seamless communication around these tools. Team members can receive notifications in Discord about new merge requests, updates on tasks within the scrum board, and discussions related to specific commits.

Being good at using tools like Discord, JIRA, and GitLab can transform the way teams operate. By improving communication, project management, and code collaboration, these tools empower teams to achieve more with less friction. We talk better, plan better, and build better things together.

Static Code Analysis Tools for Next.js

fajarriv — Mon, 11 Mar 2024 00:59:59 +0000

Writing high-quality code is not always easy, especially when we are in a team, have to deal with complex logic, multiple dependencies, and different coding styles. That's why it is important to use static analysis tools to help detect and fix errors, bugs, vulnerabilities, code smells, and other issues in our code before they cause problems.

What is Static Analysis?

Static analysis is the process of analyzing the source code of a program without executing it. It can help to find potential problems in our code, such as syntax errors, type mismatches, unused variables, security risks, performance bottlenecks, and more. Static analysis tools can also help us enforce coding standards and measure code quality.

SonarCloud/SonarQube

SonarCloud/SonarQube are cloud-based/self-hosted platforms, that provide comprehensive and continuous code quality analysis and measurement. It's a tool that scans your entire codabase, looking for bugs, code smells, duplications, and even security vulnerabilities. We can integrate Sonar with version control system, such as GitHub, GitLab, or Bitbucket. We can also automate it into our CI/CD pipeline.

To use SonarCloud or SonarQube for Next.js project, we need to follow these general steps:

Create an account on SonarCloud or install SonarQube on your server.
Create a project on SonarCloud or SonarQube and generate a token for authentication.
Install the SonarScanner tool on your local machine or your CI/CD server.
Create a sonar-project.properties file in the root directory of your project, and configure the following parameters:



# The unique identifier of your project
sonar.projectKey=your-project-key

# The name of your project
sonar.projectName=your-project-name

# The sonar host url (sonarcload/sonarqube)
sonar.host.url=

# The version of your project
sonar.projectVersion=1.0

# The source code encoding
sonar.sourceEncoding=UTF-8

# The directories where your source code is located
sonar.sources=pages,components,lib

# The directories where your test code is located
sonar.tests=test

# The directories where your coverage reports are located
sonar.javascript.lcov.reportPaths=coverage/lcov.info

Run the SonarScanner command in your terminal or your CI/CD script, and pass the token as an argument:



sonar-scanner -Dsonar.login=your-token

Wait for the analysis to complete, and then check the results on SonarCloud/SonarQube (you can simply click the given url on your terminal when the analysis is completed)

Linters and ESLint

Linters are like code style police officers. They make sure our code follows a set of rules, which can improve readability and maintainability. Linters can also enforce coding standards and best practices, such as indentation, naming, spacing, and formatting.

ESLint is a popular and widely used tool for linting JavaScript and TypeScript code. It can help us find and fix syntax errors, style issues, code smells, and more. It can also help us enforce coding standards, such as the Airbnb JavaScript Style Guide or the Google JavaScript Style Guide. ESLint is highly customizable and extensible, and supports many plugins and rules for different frameworks and libraries, such as React, Next.js, Jest, and more.

When creating a Next.js project using create-next-app, there will be prompts that asking to use EsLint or not.

When we answer the prompt 'Yes', we can already use the linter to analyze our code. To use the linter, simply run



npm run lint

SonarCloud/SonarQube and ESLint can work together to create a great quality of code for out Next.js app. SonarCloud/SonarQube takes a broad view, looking for overall code health and security, while ESLint focuses on specific coding style and catching common errors.

By using both these tools, we can ensure our Next.js app is not only functional but also clean, well-maintained, and secure.

SOLID Principle in NextJS using Typescript

fajarriv — Mon, 04 Mar 2024 11:46:20 +0000

SOLID is an acronym for five key principles of object-oriented programming that aim to improve the readability, maintainability, extensibility, and testability of code. However, SOLID principles are not limited to object-oriented programming that uses classes. They can also be applied to other paradigms, such as functional programming, that use functions, modules, or components as the main building blocks of software. With this idea, we can apply SOLID principle when building a frontend app.

Single Responsibility Principle

This principle states that a module/class/function should have only one responsibility and one reason to change. For example, we can also use custom hooks to encapsulate the logic for fetching data, managing state, or performing side effects.

For example, if we have a page/component to render list of schedules, any unrelated tasks like fetching data from server should be handled by other module.

// src/hooks/useDataSchedule.ts
export const useDataSchedule = () => {
  const fetcher = (url: string) =>
    fetch(process.env.NEXT_PUBLIC_API_URL + url).then((res) => (res.json()));

  const { data, error, isLoading, mutate } = useSWR<TSchedule[], Error>(
    '/api/schedule/list/',
    fetcher
  );
  return {
    data,
    error,
    isLoading,
    mutate,
  };
}

// src/components/schedule/ScheduleList.tsx
const ScheduleList = () => {
  // We call the hook and retrieve the Schedule
  const { data, error, isLoading, mutate } = useDataSchedule();
  if (error) return <div>Failed to load</div>
  if (isLoading) return <div>Loading...</div>
  return (
 <div>
     <h1>Schedule List:</h1>
     <ul>
      {data?.map((schedule) => (
        <li key={schedule.id}>
          <h2>{schedule.name}</h2>
          <ScheduleDetail title={schedule.detail.title}
          startTime={schedule.detail.start_time}
          endTime={schedule.detail.end_time} />
        </li>
      ))}
     </ul>
</div>
  );
};

The benefit of applying the single responsibility principle is that it makes the code more modular, maintainable, and testable. By separating the concerns of different modules, we can avoid coupling and dependency issues that may arise when changing or adding new features. We can also reuse the modules in different contexts, such as different components or pages, without duplicating the code.

Open-closed principle

A class or module should be open for extension, but closed for modification. This means that we should be able to add new features or behaviors without changing the existing code. This principle can be fulfilled when we create a reuseable components for our project.

// src/components/common/CustomButton.tsx

// Interface for the props of the button component
interface CustomButtonProps {
  text: string;
  className: string;
  onClick: () => void;
};

// A button component that takes a string and applies a tailwind class to the button element
export const CustomButton: React.FC<ColorButtonProps> = ({ text, className, onClick }) => {

  return (
    <button
      type="button"
      className={`text-white font-bold py-2 px-4 rounded ${className}`}
      onClick={onClick}
    >
      {text}
    </button>
  );
};

//src/components/modules/LoginModule/buttons.tsx
import { CustomButton } from '@components/common'

export const LandingPageModule = () => {
    return (
<div className="flex flex-col">
<CustomButton text="Login" className="bg-green" />
<CustomButton text="Create account" className="bg-gray" />
</div>
    )
}

When we have a reuseable components like above code, we can simply add add more styling to the button by passing it through the props but we can't change the default styling of the CustomButton.

Liskov substitution principle

A subclass or subcomponent should be able to replace its superclass or supercomponent without breaking the functionality. This means that we should follow the contract or interface defined by the parent class or component. The explanation may sounds a lot harder than the implementation.

We can modify the previous example to adhere Liskov substituton principle.

// src/components/common/CustomButton.tsx
// interface for the custom button component
interface ICustomButton extends ButtonHTMLAttributes<HTMLButtonElement> {
  children: ReactNode
  className: string;
};

// A button component that takes a string and applies a tailwind class to the button element
export const CustomButton:React.FC<ICustomButton> = ({ text, className, child, ...props}) => {

  return (
    <button
      type="button"
      className={`text-white font-bold py-2 px-4 rounded ${className}`}
      {...props}
    >
      {child}
    </button>
  );
};

We give the new button the attributes that we have inherited from the original button. This preserves program behavior and adhere the Liskov Substitution Principle by allowing any instance of CustomButton to be used in place of an instance of Button.

Liskov Substitution in React essentially promotes the development of a unified and adaptable component structure for creating reliable and manageable user interfaces.

Interface Segregation Principle

In React interface segregation means that components should have simple and specific interfaces that suit their purpose. We should avoid creating component interfaces that have too many or irrelevant properties or methods. This way, the code becomes more organized, easy to understand, and easy to change, as components are smaller and more focused. ISP helps improve the quality and performance of the code by using component interfaces that are clear and concise.

// src/components/schedule/ScheduleDetail.tsx
interface IScheduleDetail {
        title:string
        startTime:string
        endTime:string
}
const ScheduleDetail = ({ title, startTime, endTime}:IScheduleDetail) => {
  return (
    <div>
      <h3>{title}</h3>
      <h4>Time Duration</h4>
      <p>{startTime} - {endTime}</p>
    </div>
  );
};

To implement this principle we can simply limit the props to only what the component need.

Dependency inversion principle

This principle states that a high-level module/class should not depend on low-level module/class, both should depend abstractions, not on concretions.

For example, when we have a create schedule feature and edit schedule feature that using the same field of form, we should abstract the form to adhere this principle.

export const ScheduleForm = ({ onSubmit }: () => void) => {
  return (
    <form onSubmit={onSubmit}>
      <input name="title" />
      <input name="startTime" />
      <input name="endTime" />
    </form>
  );
};

const CreateScheduleForm = () => {
  const handleCreateSchedule = async () => {
    try {
         // Logic to handle create schedule      
    } catch (err) {
      console.error(err.message);
    }
  };
  return <ScheduleForm onSubmit={handleCreateSchedule} />;
};

const UpdateScheduleForm = () => {
  const handleUpdateSchedule= async () => {
    try {
         // Logic to handle update schedule      
    } catch (err) {
      console.error(err.message);
    }
  };
  return <ScheduleForm onSubmit={handleUpdateSchedule} />;
};

Implementing this principle will give us a better separation of concerns and more scalable code.