DEV Community: Mikhael Esa

Building SUMMARIZED: How I Built a Multi-Format Knowledge Hub with Next.js and AI

Mikhael Esa — Mon, 29 Dec 2025 14:09:39 +0000

We live in an era of information overload. We buy books we never open and save podcasts we never listen to. The intention is there—we want to learn—but the time simply isn't.

I noticed that people (myself included) often struggle to finish the content they consume. They might read the first chapter or listen to the first 10 minutes, but life gets in the way. I wanted to solve this by building SUMMARIZED: a platform that digests heavy content into accessible formats like video, audio, text, slides, and infographics.

Here is the story behind how I built it, the tech stack I used, and the surprising lessons I learned about working with AI.

The Tech Stack

To get this off the ground quickly without sacrificing performance, I stuck to a robust, modern stack:

Framework: Next.js
Styling: Tailwind CSS
Backend & Storage: Supabase

While the web framework was standard, the real challenge was the content generation pipeline. How do you take a 300-page book and turn it into a slide deck or a podcast script automatically?

The Secret Weapon: NotebookLM

I realized I didn't need to build a custom LLM pipeline from scratch when Google’s NotebookLM existed. It became the engine of the operation.

My workflow looks like this:

I gather the source material (books, articles, transcripts).
I feed them into NotebookLM.
I prompt it to generate summaries in specific formats: an audio overview, a video script, a slide deck outline, textual takeaways, and data for infographics.
I export these assets and upload them to my database.

The Storage Constraint
One technical hurdle I hit early on was the Supabase free tier limit. Storing audio and images adds up fast. To stay within the free tier boundaries, I had to implement an aggressive compression strategy for all assets before they hit the storage bucket. It taught me to be efficient with data right from the start.

Accelerating UI/UX with AI

I am a developer, not a UI designer. In the past, I would have spent weeks agonizing over padding and color palettes. This time, I leveraged AI design tools like Lovable, Bubble.io, v0, and Stitch.

This was a game-changer. Instead of designing components pixel-by-pixel, I described what I needed, and the AI generated the UI code in minutes. This allowed me to focus entirely on my area of expertise: the logic and the architecture.

The "Google Antigravity" Framework

To keep the project grounded, I used Google Antigravity to help build the project based on a set of fundamental rules I had written.

If you've ever coded with AI, you know it can hallucinate or drift off-topic. By establishing strict "rules of gravity" (fundamentals) for the project, I ensured the AI assistants stayed aligned with the project's core architecture.

Key Lessons Learned

Building SUMMARIZED taught me two massive lessons about modern software development.

1. Rules Are Everything for AI

The most time-consuming part of this project wasn't coding—it was defining the rules.
I learned that if you want AI to build complex software, you cannot just say "build this." You need to provide a rigid framework of rules. Once I nailed down these rules, the AI's output became streamlined and predictable.

The best part? This setup time is an investment. Now that I have these rules defined, I can reuse this "rule-set" for every future project to get up and running instantly.

2. Component Libraries > Custom AI Components

I initially tried to get AI to build complex UI components from scratch. It often failed or produced buggy code.

I realized that Component Libraries are the solution. AI models are excellent at reading documentation. When I instructed the AI to use a specific library and provided the docs, the output was flawless. Documentation provides the context that trial-and-error simply can't.

Final Thoughts & Try It Out

SUMMARIZED started as a way to help people consume content, but building it became a masterclass in how to leverage AI for development. By combining Next.js with NotebookLM and a rule-based AI workflow, I was able to ship a complex product in a fraction of the time it would usually take.

Want to see the result in action?

Whether you want to inspect the build or simply catch up on your reading list without spending hours, check out the live application here:

👉 https://summarized.vercel.app

A Breath of Fresh Air Amidst Framework Fatigue and Burnout

Mikhael Esa — Tue, 27 May 2025 14:37:55 +0000

Hey there, and thanks for stopping by!
I really appreciate you taking a bit of your time to read this. This post kicks off what I’m calling my “Learning Elixir Journey”, and in it, I want to share what led me to explore Elixir—especially when there are already so many hyped languages out there like Rust, Python, and others.

I’ve been working as a front-end developer for nearly five years now, mostly living in the world of React and Next.js since day one. And honestly, I’m super grateful for that ecosystem—it’s helped me land a job, build a career, and support a pretty comfortable life.

React’s always had a special place for me. Sure, there’s a new JavaScript framework popping up every week, but despite all the noise, I’ve stuck with React. It’s been reliable. Familiar.

But lately… something’s been off.

The JavaScript world moves so fast. Too fast, sometimes. Things blow up overnight and vanish just as quickly. It started to feel like I was being swept along by a current I didn’t ask to ride. I remember thinking, “Can we just slow down a bit?”

See, I’m not the kind of dev who likes chasing trends or trying every new tool for the sake of it. I care more about the concepts behind the tools—architecture, design patterns, the why behind the what. And to be honest, that’s what started bugging me: too many folks around me were using tools they didn’t really understand.

Take a friend of mine, for example, he’s super into state management libraries like Redux and Zustand. But when I asked him why those tools work the way they do, or what problems they’re actually solving under the hood, he didn’t really have an answer. Just a lot of surface-level enthusiasm.

I used to be in that same place. And at some point, I decided I didn’t want to be that kind of developer anymore.

That’s when I started building my own tools—state management, i18n, date pickers, even an ESLint plugin or two. I wanted to understand how things worked, not just use them. And you know what? I learned more than I ever expected. I don’t regret a single moment I spent going down that path.

But it came at a cost.

All that time I spent digging deep made me realize just how “fake” a lot of this world can feel. Shiny tools, loud opinions, surface-level understanding. I wanted something more grounded. More thoughtful. More… real.

And that’s when I found Elixir.

Before I stumbled upon Elixir, I was seriously considering diving into Go or Rust. I even gave both of them a try—wrote some code, followed a few tutorials—but for some reason, they just didn’t click for me.

Don’t get me wrong—both are amazing languages with strong communities and solid engineering behind them. But for whatever reason, I couldn’t find that spark, that “aha” feeling that makes you want to keep going, you know?. Maybe I’m just not ready for them yet. Maybe they just didn’t speak to the kind of developer I am right now. And that’s okay.

Elixir gave me back that feeling I’d been missing for a long time like discovering a hidden gem. I guess I’m lucky I never shy away from a bit of challenge,

I’ve learned so many new concepts along the way — OTP, the BEAM VM, memory compaction and fragmentation, the actor model, the difference between processes and threads — and all of it has reignited my passion for programming. It’s like my developer spirit woke up again.

So yeah, I’m really excited to share my journey learning Elixir with all of you. If you’re feeling stuck or restless like I was, maybe it’s time to take a step back and search for that thing your developer soul has been craving. Trust me, when you find it, you’ll come out on the other side feeling like a whole new person.

Building a Fullstack Application With Next.js + Prisma + SQLite

Mikhael Esa — Sun, 27 Apr 2025 13:32:47 +0000

TL;DR

My first thought on Next.js was "Oh it's just another front-end framework based on React" but I was wrong. Next.js is not just another front-end framework but it is a fullstack framework. Yes you heard it right, fullstack.

I have done some research about this topic and these 3 stacks suits me well for building a simple fullstack app. And I was blown away by how these 3 tech has a rich feature and gives me a huge boost in Developer Experience.

References

If you are interested in reading the documentation of each technology, then here's the link to the documentations:

Now let's go get our hands dirty.

Project Setup

First let's go with installing a fresh next.js app with this command.

$ npx create-next-app@latest

Then you can just answer the prompts but when it prompt you to use an App router, choose no as we are going to use the OG pages router 😉.

Next, we are going to setup the prisma so let's install prisma.

npm i -D prisma

After installing we will initialize prisma preconfigured with sqlite by running this command.

$ npx prisma init --datasource-provider sqlite

It will generate a prisma folder with schema.prisma file init. We will put our models inside the file so let's create some models

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
  posts Post[]
}

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  content   String?
  published Boolean @default(false)
  author    User    @relation(fields: [authorId], references: [id])
  authorId  Int
}

We have created 2 models which are User and Post where these 2 models has relation to each other.

We have models, now we have to create the DB in order to do CRUD.

$ npx prisma migrate dev --name init

It will create a migration folder inside the prisma folder.

Great! Now you have a database already setup. Next step is to create an API to do CRUD.

SSH Config for Multiple SSH Authentication

Mikhael Esa — Fri, 05 Jul 2024 12:33:49 +0000

TL;DR

Having multiple SSH keys is useful when you want to separate the purpose of each key, for example you want to have a different SSH keys for GitLab and GitHub for whatever reason. This can be achieved via the config file.

Creating Config File

To be able to have multiple ssh for different purpose, we need to create a config file inside the .ssh directory.

$ cd ~/.ssh
$ touch config
$ vim config

The commands above will directs us to the .ssh directory and creates the config file and then uses vim to edit the content. You can use other editor like nano, it's up to you.

Now let's edit the config file to look like this.

Host gitlab.com
    HostName gitlab.com
    User git
    IdentityFile ~\.ssh\my_gitlab_ssh
    IdentitiesOnly yes

Host github.com
    HostName github.com
    User git
    IdentityFile ~\.ssh\my_github_ssh
    IdentitiesOnly yes

Now there you have it, a ssh config file for multiple SSH keys. You are not limited to only GitHub and GitLab, you can also use it for server authentication and many more.

~ Dadah 👋

How to Configure ESLint for TypeScript Projects

Mikhael Esa — Tue, 18 Jun 2024 13:41:03 +0000

TL;DR

One thing that is important in projects but often neglected is code style and standardization. Fortunately for those who really wants to enforce certain code style or standards to their projects, eslint got our back!

ESLint is quite easy to setup but when you add typescript, then the complexity increases a little bit but don't be afraid as this article will guide you through it.

Installing Essential Packages

before we can use eslint, we must install some essential packages.

$ npm install -D -E eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

eslint: Provides a flexible configuration system that allows you to define custom rules or leverage existing rule sets for specific coding styles
@typescript-eslint/parser: A parser plugin specifically designed for ESLint to handle TypeScript code.
@typescript-eslint/eslint-plugin: Provides a collection of ESLint rules specifically designed for TypeScript code.

Setting up the ESLint

Now that we have installed the essential packages, we can now start creating the eslint config. Let's start by creating a file called .eslintrc.json and inside the file we write the following.

{
  "parser": "@typescript-eslint/parser",
  "plugins": [
    "@typescript-eslint",
  ],
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
  parserOptions: {
    sourceType: "module",
    ecmaVersion: 2023,
  },
}

parser: "@typescript-eslint/parser": This line specifies the parser ESLint should use. Setting it to @typescript-eslint/parser ensures that ESLint can understand the syntax and types specific to TypeScript code.
plugins: ["@typescript-eslint"]: This section defines the plugins used for linting. This plugin provides a collection of rules specifically designed for TypeScript code.
extends: ["eslint:recommended", "plugin:@typescript-eslint/recommended"]: This section defines the base configurations that our setup inherits from.
- "eslint:recommended": This extends your configuration with ESLint's recommended set of rules for JavaScript code
- "plugin:@typescript-eslint/recommended": This extends our configuration with the recommended set of rules from the @typescript-eslint plugin
sourceType: "module":This option specifies the type of source code being parsed. Here, it's set to "module", indicating that the code is expected to be written in a module system like ES modules
ecmaVersion: 2023: This option specifies the ECMAScript version that the parser should expect the code to be written in.

That's the configuration that we needed, as well as the explanation for each properties.

Exploring the Rules

Now after setting up the ESLint, you are left with exploring the various rules of eslint and match it into your liking. You can explore the available rules in ESLint docs and TypeScript ESLint docs.

If you don't feel like exploring the rules and want to just install a plugin, don't worry we got your back. We have made a plugin that is curated and tailored to improve your productivity, project's maintainability, and type safety. Check out our eslint-plugin-typescript as well as eslint-plugin-typescript-react

How to Setup Jest on Typescript Monorepo Projects

Mikhael Esa — Wed, 12 Jun 2024 14:38:30 +0000

TL;DR

When I started making open source libraries, I didn't know much about unit testing in terms of writing the tests, and setting up the environment. There was a strong voice that told me to write unit tests for my open source libraries because if one day it gets big (hopefully) it wouldn't be efficient to test every functionality manually.

Acknowledging the benefits of unit testing, I jumped right in to the one and only Jest. Honestly it overwhelms me a little bit too much when I read the docs and there are a lot of things going on in there. But I didn't lose spirit by just reading a docs, otherwise I wouldn't call myself a learner 😅

The challenges

Because it was the first time I'm learning unit testing using Jest, I'm confused on how to set things up and running in my project. Most of my projects are using typescript + monorepo structure and it requires a specific config to make it running. Without further a do, let's dive right into it.

Setting up

In this section, we'll go through the steps on how to configure Jest in Typescript Monorepo project so please follow along and read the steps carefully.

Installation

First of all, we have to install a few packages as devDependencies especially if we are using typescript, there are extra packages that we must install.

$ npm i -D jest @types/jest ts-jest ts-node typescript

jest: Is the tool for writing unit tests and run the tests
@types/jest: Contains type definitions for jest
ts-jest: A Jest transformer that allows us to use Jest for testing TypeScript code.
ts-node: Allows us to run TypeScript code directly in Node.js without needing to precompile it to JavaScript
typescript: You know what it is

After installing those packages, you can check your package.json to see if they are listed in devDependencies.

Jest config

Let's create a jest.config.ts in the root of our project and write this

import type { Config } from "@jest/types";

const config: Config.InitialOptions = {
  verbose: true,
  preset: "ts-jest",
  testEnvironment: "node",
  transform: {
    "^.+\\.(ts|tsx)$": "ts-jest",
  },
  projects: [
    {
      testPathIgnorePatterns: ["<rootDir>/node_modules/"],
      preset: "ts-jest",
      displayName: "my-package",
      testMatch: ["<rootDir>/packages/my-package/__tests__/**/*.spec.ts"],
    }
  ],
};
export default config;

Here is the explanation for each

verbose: To show a verbose version of test reports.
preset: A pre-configured set of settings and configurations for Jest.
testEnvironment: The test environment that will be used for testing.
transform: Specifies how different types of files should be processed before running the tests
projects: Allows us to define multiple sets of configurations within a single Jest setup.
testPathIgnorePatterns: An array of regular expression patterns that Jest uses to ignore test files
displayName: A name to identify our project like an alias.
testMatch: Specify the glob patterns that Jest uses to detect test files.

The configuration above assumes that your project structure look like this.

| - - packages
| - - - my-package
| - - - - __tests__
| - - - - - test.spec.ts
| - tsconfig.base.json

Inside you root package.json, you can create a script to run the test on a specific project.

"script":{
  "test:my-package": "jest --selectProjects=my-package"
}

Writing tests

Now assuming that you have followed the configurations above, it's time for us to create our first test case. Inside the __tests__ folder, create a file named test.spec.ts and write a dummy test to see if the configurations work perfectly.

describe("Test config", () => {
  it("counts correctly", ()=>{
    expect(1 + 1).toBe(2);
  })
})

After writing the sample test, make sure you are in root directory and run the test script.

npm run test:my-package

Conclusion

Unit testing using Jest is fun but can overwhelm new learners especially when configuring the Jest itself in order for it to work properly. The complexity even increases when we use different architecture such as monorepo. In spite of the complexity that Jest introduces, Jest is still a powerful testing tool that is used by many developers to test their projects, so it's worth it to learn Jest :).

~ Dadah 👋

How I Achieved Maintanability, and Scalability in My Projects

Mikhael Esa — Sat, 11 May 2024 20:14:16 +0000

TL;DR

As I stepped into my new role as a Frontend Developer, I encountered a disorganized landscape devoid of standardization. The codebases resembled tangled mazes, hindering rather than facilitating progress.

In the world of software development, maintainability and scalability are paramount. Yet, here I was, facing a reality that contradicted these principles. Determined to effect change, I embarked on a mission to establish standards amidst the chaos.

First Objective: Find the Correct Technologies

While prioritizing user-friendly technologies with clear benefits sounds ideal, it can lead to oversaturating your tech stack. This complexity can create a difficult-to-manage environment with a steep learning curve, especially if you incorporate advanced tools.

We took our time evaluating different options and ultimately landed on a focused set of technologies: Next.js, TypeScript, Redux Toolkit, SASS, and Axios. This combination offers a powerful and manageable foundation for our project, avoiding the pitfalls of an overly complex tech stack.

Second Objective: Building a Fortress

Recognizing the importance of a well-structured project, we embarked on a deep dive into the world of architectural patterns and best practices.

We explored the elegance of the Atomic Design System, which allows us to build complex UIs from reusable components. Feature-based structures provided a clear organization, ensuring each section of the project is self-contained and easy to manage. Additionally, we embraced the power of decoupling, ensuring components are independent and avoid unnecessary dependencies. File co-location kept related code physically close, fostering better maintainability.

By thoughtfully combining these techniques, we meticulously crafted a robust and well-rounded project structure that will serve as a solid foundation for future development.

Third Objective: Code Cohesion

Recognizing the power of a united front, we prioritized code standardization to streamline collaboration and minimize confusion within our development squad. This meant establishing a shared codebase dialect – a set of agreements on naming conventions, standardized code boilerplate, and other essential elements.

To ensure everyone speaks the same coding language, we leverage the power of ESLint and Stylelint, enforcing these rules and preventing integration nightmares down the road. But that's not all! Husky and Lint-Staged act as our vigilant pre-commit sentinels, automatically identifying potential code quality slips before they ever reach the sacred halls of GitHub.

By combining these efforts, we've forged a unified codebase, fostering a collaborative environment where developers can focus on building amazing features, not deciphering cryptic code.

Fourth Objective: Crafting the Code Codex

We believe in the power of clear documentation, especially for code that will be used by others. We start by meticulously documenting our template codebase, providing a solid foundation for newcomers. Furthermore, we encourage a culture of developer-driven documentation throughout the development process. This documentation falls into three key categories:

Global Code Chronicles: In-depth explanations for our shared codebase, ensuring everyone understands its usage and functionality.
Feature Roadmaps: Detailed documentation for each feature, outlining its purpose and key details. This prevents information gaps and streamlines future development.
Code Snippet Sidebars (Optional): While lower priority, documentation for isolated code serves as a helpful reference, fostering overall codebase understanding.

This multi-layered approach ensures a comprehensively documented codebase – a roadmap for developers of all experience levels.

Fifth Objective: Adapting to Challenges

The path of software development rarely adheres to a strictly linear course. There will be times when elegant solutions demand a touch of creative deviation from the norm. Recognizing this reality, we foster a culture of continuous learning within our development team. We encourage developers to delve into the vast landscape of code patterns and best practices, equipping them with a versatile toolkit for tackling any coding challenge.

In the context of our React-based project, this translates to a deep understanding of powerful patterns like compound components, Higher-Order Components (HOCs), and render props. By empowering our developers with this knowledge, we unlock a strategic advantage: the ability to tailor solutions to specific needs. Even if a solution isn't a textbook example of a particular pattern, a well-considered and well-implemented adaptation can significantly improve the long-term health of our codebase. This adaptability, combined with a foundation of best practices, allows us to prioritize maintainability without sacrificing functionality.

Furthermore, we encourage a spirit of self-reliance within our team. While third-party packages offer convenience, we believe in the value of crafting custom solutions whenever feasible. This approach not only grants us greater control over our codebase but also fosters a deeper understanding of the underlying mechanisms at play. By building solutions from the ground up, developers gain invaluable insights into the intricate workings of the technologies they utilize.

In essence, we weave these patterns into the fabric of our code, creating a resilient and adaptable codebase that serves as a testament to the collective ingenuity of our development team. This commitment to both adaptability and self-reliance empowers us to navigate the ever-evolving landscape of software development with creativity, efficiency, and a profound understanding of the craft.

Conclusion

Many tech companies fall prey to the chaos of inconsistent code. We chose a different path – a well-defined tech stack, a fortress of organization, and the power of code standardization. By fostering a culture of continuous learning and self-reliance, we've built a codebase that's not just functional, but a foundation for future brilliance.

Thanks for reading. Dadah ~ 👋

What is useState in React?

Mikhael Esa — Tue, 17 Oct 2023 15:00:00 +0000

useState

useState is a React hook used in functional components to manage and update component-specific state. It takes an initial value and returns an array with the current state value and a function to update that state. This allows you to handle dynamic data within your component, such as counters, form inputs, or any changing values.

In my own experience as a React Dev, this hook is one of the hooks that I use the most. It's like we as a React Dev cannot live without it 😆

How to Use State

useState is one of the simplest hook and a very useful one. Let's see how we can use it in our app

export default function Home() {
  // const [getter, setter] = useState(optionalInitialState)
  const [count, setCount] = useState(0);

  // Using the state
  return <button>{count}</button>;
}

useState returns an array where the first item is the getter and the second item is the setter. useState can also take an initial state by passing your desired value as the params. It is a common practice to prefix the setter with set followed by the state name like the example above.

Using the state is like using a regular variable. You can just call it inside the component. If you want to use it inside the tags, then you have to wrap it inside a curly bracket.

Setter is a function to update our state. Updating a state will trigger a re-render to our component and the component's children. We shouldn't mutate our state without using the setter to maintain predictability, immutability, and proper performance. Let's see how we can use it.

...
  <button onClick={() => setCount(1)}>Current number: {count}</button>
...

In the example above, we create a click event to set our state to 1. Great it works but, what if we want to keep incrementing it everytime we click the button? Easy, setState also accepts a callback as a parameter, we can also access the current state through the callback.

...
  <button onClick={() => setCount((current) => current += 1)}>Current number: {count}</button>
...

There we have it! We accessed the current state through the setter and we return the new value for the state. To make it look cleaner and easier to manage, we can put the setter inside a function instead.

...
  const handleIncrement = () => setCount((current) => (current += 1));
  return <button onClick={handleIncrement}>Current number: {count}</button>;
...

What's next?

Now that you have learned about useState, try creating some basic app and try to involve useState. If you have any question, feel free to drop a comment and if you liked this article, please give a like and follow me to get an update of this series.

Dadah~ 👋

Dependency Inversion Principle in React

Mikhael Esa — Sat, 14 Oct 2023 14:54:01 +0000

D (Dependency Inversion Principle)

High-level modules should not depend on low-level modules, but rather both should depend on abstractions

Dependency Inversion in React involves ensuring that high-level components don't directly depend on low-level components. Instead, both should rely on abstractions, like props or context, to foster flexibility and maintainability. This promotes modularity, simplifies testing, and allows for easier code maintenance.

Adhering to the Dependency Inversion Principle in React leads to a more scalable architecture with better separation of concerns. It simplifies unit testing by enabling easy mockup of low-level components, enhancing control and precision in testing high-level components.

const CreateBookForm = () => {
  const handleCreateBookForm = async (e: FormEvent<HTMLFormElement>) => {
    try {
      const formData = new FormData(e.currentTarget);
      await axios.post("https://myapi.com/books", formData);
    } catch (err) {
      console.error(err.message);
    }
  };

  return (
    <form onSubmit={handleCreateBookForm}>
      <input name="title" />
      <input name="author" />
      <input name="bookType" />
    </form>
  );
};

The component above shows a form for handling create book by rendering a form and send the submitted data to an api.

Let's imagine if there's another form to edit the book with 100% same ui and differs only from logic. The dependency to the logic of sending data to the API is what makes the form unreusable, so we have to make a component that doesn't depend on a low-level module.

const BookForm = ({ onSubmit }) => {
  return (
    <form onSubmit={onSubmit}>
      <input name="title" />
      <input name="author" />
      <input name="bookType" />
    </form>
  );
};

We have removed the dependency from the form and we can pass the logic through props.

Now let's use the form!

const CreateBookForm = () => {
  const handleCreateBook = async (e: FormEvent<HTMLFormElement>) => {
    try {
      const formData = new FormData(e.currentTarget);
      await axios.post("https://myapi.com/books", formData);
    } catch (err) {
      console.error(err.message);
    }
  };
  return <BookForm onSubmit={handleCreateBook} />;
};

const EditBookForm = () => {
  const handleEditBook = async (e: FormEvent<HTMLFormElement>) => {
    try {
      // Another logic
    } catch (err) {
      console.error(err.message);
    }
  };
  return <BookForm onSubmit={handleEditBook} />;
};

See now that we have implemented Dependency Inversion Principle, we have a great separation of concerns by abstracting the dependency

What's next?

This is the last part of our Apply SOLID in React series. Now that you have a good understanding of SOLID, it's time for you to implement these principles and see how powerful and impactful your codes can be.

Dadah~ 👋

Interface Segregation Principle in React

Mikhael Esa — Sun, 08 Oct 2023 06:01:07 +0000

I (Interface Segregation Principle)

No code should be forced to depend on methods it does not use

In React, the Interface Segregation Principle (ISP) emphasizes the importance of creating precise and minimal interfaces for components. It encourages developers to design component interfaces that are tailored to specific needs, avoiding unnecessary bloat.

This approach results in more modular, maintainable, and reusable code, as components become smaller and focused, promoting better readability and scalability in React applications. ISP encourages cleaner, efficient codebases by advocating for lean and specialized component interfaces.

const Book = ({ book }) => {
  return (
    <div>
      <img src={book.image} alt="Book image" />
      <p>{book.title}</p>
      <p>{book.author}</p>
    </div>
  );
};

We have a book component which only need few data from the book props which are image, title, and author. By giving it book as a props, we end up giving it more than the component actually need because the book props itself might contain data that the component doesn't need

To mitigate this problem we can limit the props to only what the component need.

const Book = ({ image, title, author }) => {
  return (
    <div>
      <img src={image} alt="Book image" />
      <p>{title}</p>
      <p>{author}</p>
    </div>
  );
};

By doing so, we are applying the ISP principle, thus avoiding clients of our component from depending on an interface they are not using.

What's next?

Let's not stop here since there is 1 principle left to learn in SOLID which I will cover in the next article so stay tuned.

Dadah~ 👋

Liskov Substitution Principle in React

Mikhael Esa — Fri, 06 Oct 2023 06:36:04 +0000

L (Liskov Substitution Principle)

Objects of a superclass should be replaceable with objects of its subclasses without breaking the application

In React, the Liskov Substitution Principle (LSP) underscores the importance of allowing child components to seamlessly replace their parent components while maintaining the same interface and functionality. This enables developers to compose complex user interfaces by substituting components, promoting code reusability and maintainability.

By adhering to LSP in React, developers create a hierarchy of interchangeable components. This means that base components and their derived counterparts can be swapped without affecting the application's core functionality, simplifying development, enhancing code readability, and facilitating better component behavior understanding. In essence, Liskov Substitution in React encourages the creation of a flexible and cohesive component structure for building robust and maintainable user interfaces.

The implementation is actually not as sophisticated as the explanation. Don't believe me? See for yourself 😉.

const DangerButton = () => {
  return <div>Danger</div>;
};

So we want to create a DangerButton component but a button functionality couldn't be replaced by a div so this violates the principle.

What we should do instead is just return a button like this

const DangerButton = () => {
  return <button>Danger</button>;
};

This looks better but it's not enough. We also need to inherit all the functionalities of the button itself.

interface IDangerButtonProps extends ButtonHTMLAttributes<HTMLButtonElement> {
  children: ReactNode
  // Your extra props if you have
}

const DangerButton = ({ children, ...props }: IDangerButtonProps) => {
  return <button {...props} className="danger">{children}</button>;
};

Now we have inherited all of the attributes of the button and we pass the attributes to the new button. This way, any instance of DangerButton can still be used in place of an instance of Button without changing the program’s behavior and complying with the Liskov Substitution Principle.

What's next?

Let's not stop here since there are 2 more principles left to learn in SOLID which I will cover in the next article so stay tuned.

Dadah~ 👋

Ionic 7 + React Project Setup and Android Studio Live Reload and Debug on Real Device

Mikhael Esa — Wed, 04 Oct 2023 04:57:25 +0000

Install Ionic CLI

$ npm i -g @ionic/cli

Run this command to scaffold project

$ ionic start my-app tabs --type=react --capacitor

Install android studio latest version. link here
cd into your ionic project and run these command for android environment

$ ionic build
$ ionic cap add android
$ ionic cap open android

It will build your app and setup the android environment also open the android studio.

If it's your first time downloading android studio, then it will download the necessary resources first automatically.
When the installation is done and nothing is going wrong, then press the play button on the navbar or press Shift + F10
Install JDK 20
extract JDK
Set environment variable for JAVA_HOME targeting the JDK directory
Run this command for live reload on android studio and on browser

$ ionic cap run android -l --external

Run on Real device (Android)

Download and install ADB. link
Extract adb
Create an environment Path variable targeting the extracted adb directory
Enable developer mode on your phone and enable USB debugging. docs
Connect your phone to your pc and run adb from command prompt. If there's a popup in your phone asking to allow access from PC, then allow it.
Finally run this command to install debug version of the apk on your phone

$ ionic cap run android -l --external