Forem: ugurgunes95

SOLID Principles of Object Oriented Design and Architecture

ugurgunes95 — Sun, 22 Jun 2025 15:12:48 +0000

In this article I'm going to explain SOLID principles with bad and correct examples using typescript. Let's get started!

Single Responsibility Principle(SRP)

Each class should have only one responsibility.🙄
You should be able to describe what each class does without saying "and".🤔
Each class should have only one reason to change.👍🏼
A class should contain code that changes for the same single reason.

Responsibility = reason to change
We can simply describe it as single reason to change principle.

Bad Example That Violates SRP

class UserService {
  getUser(id: number) {
    // Gets user from database
    console.log(`Fetching user with ID: ${id}`);
    return { id, name: "John Doe", email: "john@example.com" };
  }

  saveUser(user: { id: number, name: string, email: string }) {
    // Saves user to database
    console.log(`Saving user: ${JSON.stringify(user)}`);
  }

  sendWelcomeEmail(email: string) {
    // Sends welcome email
    console.log(`Sending welcome email to: ${email}`);
  }
}

In this example UserService has three responsibilities:
- Saving a user's information,
- Getting a user's information,
- Sending welcome e-mail to new users.
If the logic of sending mail changes(I.E.: Using another email provider) we will have to change UserService which violates SRP.

Correct Example That Respects SRP

// Class that manages user actions
class UserRepository {
  getUser(id: number) {
    console.log(`Fetching user with ID: ${id}`);
    return { id, name: "John Doe", email: "john@example.com" };
  }

  saveUser(user: { id: number; name: string; email: string }) {
    console.log(`Saving user: ${JSON.stringify(user)}`);
  }
}

// Class that manages sending emails
class EmailService {
  sendWelcomeEmail(email: string) {
    console.log(`Sending welcome email to: ${email}`);
  }
}

// Service that manages user operations
class UserService {
  private userRepository: UserRepository;
  private emailService: EmailService;

  constructor(userRepository: UserRepository, emailService: EmailService) {
    this.userRepository = userRepository;
    this.emailService = emailService;
  }

  registerUser(name: string, email: string) {
    const user = { id: Date.now(), name, email };
    this.userRepository.saveUser(user);
    this.emailService.sendWelcomeEmail(email);
  }
}

// Usage
const userRepository = new UserRepository();
const emailService = new EmailService();
const userService = new UserService(userRepository, emailService);

userService.registerUser("Alice", "alice@example.com");

This code snippet is the same as above but takes SRP into account:
- UserRepository manages only database operations.
- EmailService manages only email sending operations.
- UserServive only manages the business logic and externalizes the dependencies.
- If the method of sending email changes, simply changing the EmailService class is sufficient.
- The code becomes more modular, testable and extensible.

Open Closed Principle (OCP)

Software entities(classes, modules, functions etc.) should be open for extension, but closed for modification.
Depend on stable abstractions and modify system's behavior by providing different realizations
OCP is the principle of Polymorphism.

Bad Example That Violates OCP

class PaymentProcessor {
  processPayment(type: string, amount: number) {
    if (type === "credit_card") {
      console.log(`Processing credit card payment of $${amount}`);
    } else if (type === "paypal") {
      console.log(`Processing PayPal payment of $${amount}`);
    } else {
      throw new Error("Invalid payment method");
    }
  }
}

// Usage
const payment = new PaymentProcessor();
payment.processPayment("credit_card", 100);
payment.processPayment("paypal", 200);

❌ Problems:
- If we want to add a new payment method (for example, Bitcoin), we need to modify the existing code.
- If-else blocks must be added to the processPayment method for each new payment method.

Correct Example That Respects OCP

// We create an interface for the payment method
interface PaymentMethod {
  pay(amount: number): void;
}

// Credit card payment class
class CreditCardPayment implements PaymentMethod {
  pay(amount: number) {
    console.log(`Processing credit card payment of $${amount}`);
  }
}

// PayPal payment class
class PayPalPayment implements PaymentMethod {
  pay(amount: number) {
    console.log(`Processing PayPal payment of $${amount}`);
  }
}

// Bitcoin payment class (We don't need to change old code to add new features!)
class BitcoinPayment implements PaymentMethod {
  pay(amount: number) {
    console.log(`Processing Bitcoin payment of $${amount}`);
  }
}

// The main payment processor outsources the dependency
class PaymentProcessor {
  private paymentMethod: PaymentMethod;

  constructor(paymentMethod: PaymentMethod) {
    this.paymentMethod = paymentMethod;
  }

  process(amount: number) {
    this.paymentMethod.pay(amount);
  }
}

// Usage
const creditCardPayment = new PaymentProcessor(new CreditCardPayment());
creditCardPayment.process(100);

const paypalPayment = new PaymentProcessor(new PayPalPayment());
paypalPayment.process(200);

const bitcoinPayment = new PaymentProcessor(new BitcoinPayment());
bitcoinPayment.process(300);

🚀 Advantages:
- We can add new payment methods without changing the existing code.
- The code becomes more modular and flexible.
- Since it takes dependencies from outside, it is more testable with Dependency Injection.

Liskov Substitution Principle (LSP)

If S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of that program(correctness, task performed, etc.).
Rules:
- Method Signature Rules:
- Contravariance of Arguments: Subtypes must not add new constraints to method parameters.
- Covariance of Result: Subtypes must not change the return type of a method.
- Exception Rule: Subtypes must not throw more exceptions than their supertypes.
- Pre-Condition Rule: Subtypes must not weaken preconditions (make them less strict).
- Post-Condition Rule: Subtypes must not strengthen postconditions (make them more strict).
- Class Property Rules:
- Invariant Rule: Subtypes must preserve invariants.
- Constraint Rule: Subtypes must not add new constraints.

Bad Example That Violates LSP's Method Signature Rules

class Bird {
  fly(): string {
    return "Flying";
  }
}

class Penguin extends Bird {
  // Violeates LSP! Penguin doesn't fly.
  fly(): string {
    throw new Error("Penguins cannot fly");
  }
}

function makeBirdFly(bird: Bird) {
  console.log(bird.fly());
}

const bird = new Bird();
const penguin = new Penguin();

makeBirdFly(bird); // Output: "Flying"
makeBirdFly(penguin); // Runtime Error: Penguins cannot fly

❌ Problems:
- Penguin should be able to replace the Bird class. However, the Penguin class breaks the fly method and throws an error.
- This violates LSP.

Correct Example That Respects LSP's Method Signature Rules

class Bird {
  move(): string {
    return "Moving";
  }
}

class FlyingBird extends Bird {
  fly(): string {
    return "Flying";
  }
}

class Penguin extends Bird {
  swim(): string {
    return "Swimming";
  }
}

function makeBirdMove(bird: Bird) {
  console.log(bird.move());
}

function makeBirdFly(bird: FlyingBird) {
  console.log(bird.fly());
}

const eagle = new FlyingBird();
const penguin = new Penguin();

makeBirdMove(eagle); // Output: "Moving"
makeBirdMove(penguin); // Output: "Moving"
makeBirdFly(eagle); // Output: "Flying"
// makeBirdFly(penguin); // TypeScript error: Penguin does not have 'fly' method.

🚀 Advantages:
- We wrote our code without violating the Liskov Substitution Principle (LSP) by separating flight and flightless birds into different classes.

Bad Example That Violates LSP's Pre-Condition Rule

class DiscountService {
  applyDiscount(price: number): number {
    if (price < 0) {
      throw new Error("Price cannot be negative");
    }
    return price * 0.9; // 10% discount
  }
}

class VIPDiscountService extends DiscountService {
  applyDiscount(price: number): number {
    if (price < 100) {
      throw new Error("VIP discount is only applicable for prices above 100");
    }
    return price * 0.8; // 20% discount for VIP customers
  }
}

function processDiscount(service: DiscountService, price: number) {
  console.log(service.applyDiscount(price));
}

const standardService = new DiscountService();
const vipService = new VIPDiscountService();

processDiscount(standardService, 50); // Output: 45
processDiscount(vipService, 50); // Runtime Error: "VIP discount is only applicable for prices above 100"

❌ Problems:
- VIPDiscountService requires the price to be greater than 100 in the applyDiscount method.
- Adding a restriction in a subclass when there is no such restriction in the superclass violates the Pre-Condition Rule.
- Because a code that uses the superclass (processDiscount function) encounters an unexpected error in the subclass.

Correct Example That Respects LSP's Pre-Condition Rule

class DiscountService {
  applyDiscount(price: number): number {
    if (price < 0) {
      throw new Error("Price cannot be negative");
    }
    return price * 0.9;
  }
}

class VIPDiscountService extends DiscountService {
  applyDiscount(price: number): number {
    if (price < 0) {
      // We did not change the rule!
      throw new Error("Price cannot be negative");
    }
    return price * 0.8;
  }
}

function processDiscount(service: DiscountService, price: number) {
  console.log(service.applyDiscount(price));
}

const standardService = new DiscountService();
const vipService = new VIPDiscountService();

processDiscount(standardService, 50); // Output: 45
processDiscount(vipService, 50); // Output: 40

🚀 Advantages:
- VIPDiscountService can seamlessly replace the parent class because it does not add any extra restrictions.
- We made it compatible with the Pre-Condition Rule.
- Now wherever DiscountService is used, VIPDiscountService can also be used.

Bad Example That Violates LSP's Post-Condition Rule

class Rectangle {
  protected width: number;
  protected height: number;

  constructor(width: number, height: number) {
    this.width = width;
    this.height = height;
  }

  setWidth(width: number) {
    this.width = width;
  }

  setHeight(height: number) {
    this.height = height;
  }

  getArea(): number {
    return this.width * this.height; // Area calculation
  }
}

class Square extends Rectangle {
  constructor(side: number) {
    super(side, side);
  }

  setWidth(width: number) {
    this.width = width;
    this.height = width; // We're changing the height too
  }

  setHeight(height: number) {
    this.width = height; // We're changing the width too
    this.height = height;
  }
}

function calculateArea(rect: Rectangle) {
  rect.setWidth(10);
  rect.setHeight(5);
  console.log(rect.getArea());
}

const rect = new Rectangle(4, 6);
calculateArea(rect); // Output: 50

const square = new Square(4);
calculateArea(square); // Output: 25 ❌ (Expected 50 but result is 25!)

❌ Problems:
- The Square class should be used instead of the Rectangle class.
- However, Square changes the setWidth and setHeight methods, breaking the expected result.
- The calculateArea function gets a different result than the object it considers a rectangle.
- This violates the Post-Condition Rule because the getArea method no longer provides the output guaranteed in the superclass.

Correct Example That Respects LSP's Post-Condition Rule

interface Shape {
  getArea(): number;
}

class Rectangle implements Shape {
  protected width: number;
  protected height: number;

  constructor(width: number, height: number) {
    this.width = width;
    this.height = height;
  }

  setWidth(width: number) {
    this.width = width;
  }

  setHeight(height: number) {
    this.height = height;
  }

  getArea(): number {
    return this.width * this.height;
  }
}

class Square implements Shape {
  private side: number;

  constructor(side: number) {
    this.side = side;
  }

  setSide(side: number) {
    this.side = side;
  }

  getArea(): number {
    return this.side * this.side;
  }
}

function calculateShapeArea(shape: Shape) {
  console.log(shape.getArea());
}

const rect = new Rectangle(10, 5);
calculateShapeArea(rect); // Output: 50

const square = new Square(4);
calculateShapeArea(square); // Output: 16 ✅ (Expected behavior)

🚀 Advantages:
- Rectangle and Square are now defined as independent classes.
- Rectangle works according to the logic of a rectangle, while Square has its own rules.
- The Liskov Substitution Principle is preserved because the calculateShapeArea function gets the expected result for every shape.

Bad Example That Violates LSP's Class Property Rule

class Employee {
  name: string;
  salary: number;

  constructor(name: string, salary: number) {
    this.name = name;
    this.salary = salary;
  }

  getSalary(): number {
    return this.salary;
  }
}

class Manager extends Employee {
  salary: string; // ❌ We are using a different data type!

  constructor(name: string, salary: number) {
    super(name, salary);
    this.salary = `$${salary} per year`; // ❌ We are storing a string instead of a number
  }

  getSalary(): string {
    // ❌ Return type has changed
    return this.salary;
  }
}

function printEmployeeSalary(employee: Employee) {
  console.log(`Salary: ${employee.getSalary()}`);
}

const emp = new Employee("Alice", 5000);
printEmployeeSalary(emp); // Output: Salary: 5000

const manager = new Manager("Bob", 7000);
printEmployeeSalary(manager);

❌ Problems:
- While the salary property should be a number, the Manager class changed its meaning by making it a string.
- Changing the type or meaning of a property in a superclass violates LSP.
- printEmployeeSalary function expects number but receives string.

Correct Example That Respects LSP's Class Property Rule

class Employee {
  name: string;
  salary: number;

  constructor(name: string, salary: number) {
    this.name = name;
    this.salary = salary;
  }

  getSalary(): number {
    return this.salary;
  }
}

class Manager extends Employee {
  bonus: number;

  constructor(name: string, salary: number, bonus: number) {
    super(name, salary);
    this.bonus = bonus;
  }

  getTotalSalary(): number {
    return this.salary + this.bonus;
  }
}

function printEmployeeSalary(employee: Employee) {
  console.log(`Salary: ${employee.getSalary()}`);
}

const emp = new Employee("Alice", 5000);
printEmployeeSalary(emp); // Output: Salary: 5000

const manager = new Manager("Bob", 7000, 2000);
printEmployeeSalary(manager); // Output: Salary: 7000 ✅ as expected
console.log(`Total Salary: ${manager.getTotalSalary()}`); // Output: Total Salary: 9000 ✅

🚀 Advantages:
- The salary property remains as number in both classes.
- The Manager class added an extra bonus feature but did not change the meaning of the salary.
- The printEmployeeSalary function worked as expected.

Interface Segregation Principle (ISP)

Clients should not be forced to depend on methods they do not use. Instead, clients should only depend on the minimum set of interfaces that are necessary for their functionality.

Bad Example That Violates ISP

interface Worker {
  work(): void;
  eat(): void;
}

class Developer implements Worker {
  work(): void {
    console.log("Writing code...");
  }

  eat(): void {
    console.log("Eating lunch...");
  }
}

class Designer implements Worker {
  work(): void {
    console.log("Designing UI...");
  }

  eat(): void {
    console.log("Eating lunch...");
  }
}

class Robot implements Worker {
  work(): void {
    console.log("Executing automated tasks...");
  }

  // ❌ Problem: Robot does not eat, but it has to implemet `eat()` method!
  eat(): void {
    throw new Error("Robots do not eat!");
  }
}

❌ Problems:
- The Robot class has to implement the eat() method, but robots don't eat!
- ISP is violated because all classes are forced to implement methods that they do not use.

Correct Example That Respects ISP

interface Workable {
  work(): void;
}

interface Eatable {
  eat(): void;
}

class Developer implements Workable, Eatable {
  work(): void {
    console.log("Writing code...");
  }

  eat(): void {
    console.log("Eating lunch...");
  }
}

class Designer implements Workable, Eatable {
  work(): void {
    console.log("Designing UI...");
  }

  eat(): void {
    console.log("Eating lunch...");
  }
}

class Robot implements Workable {
  work(): void {
    console.log("Executing automated tasks...");
  }
}

// Test
const dev = new Developer();
dev.work(); // Output: "Writing code..."
dev.eat(); // Output: "Eating lunch..."

const robot = new Robot();
robot.work(); // Output: "Executing automated tasks..."
// robot.eat(); // ❌ Error: Robot does not have `eat()` method, because it doesn't required now.

🚀 Advantages:
- We created two small interfaces: Workable and Eatable.
- The robot no longer has to implement the eat() method.
- Each class implements only the methods it needs.

Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.

Bad Example That Violates DIP

class LightBulb {
  turnOn(): void {
    console.log("LightBulb is ON");
  }

  turnOff(): void {
    console.log("LightBulb is OFF");
  }
}

class Switch {
  private lightBulb: LightBulb;

  constructor(lightBulb: LightBulb) {
    this.lightBulb = lightBulb;
  }

  operate(): void {
    this.lightBulb.turnOn();
  }
}

// Usage
const bulb = new LightBulb();
const mySwitch = new Switch(bulb);
mySwitch.operate(); // Output: "LightBulb is ON"

❌ Problems:
- Switch is directly dependent on the LightBulb class.
- If we want to add a LEDLight or a Fan instead of the LightBulb, we have to change the Switch class.
- The code becomes harder to extend and flexibility is lost.

Correct Example That Respects DIP

// 1. Abstraction
interface Switchable {
  turnOn(): void;
  turnOff(): void;
}

// 2. LightBulb implements the abstraction
class LightBulb implements Switchable {
  turnOn(): void {
    console.log("LightBulb is ON");
  }

  turnOff(): void {
    console.log("LightBulb is OFF");
  }
}

// 3. Let's add another device
class LEDLight implements Switchable {
  turnOn(): void {
    console.log("LED Light is ON");
  }

  turnOff(): void {
    console.log("LED Light is OFF");
  }
}

// 4. Switch is no longer dependent on a specific class, but on the `Switchable` interface!
class Switch {
  private device: Switchable;

  constructor(device: Switchable) {
    this.device = device;
  }

  operate(): void {
    this.device.turnOn();
  }
}

// Usage
const bulb = new LightBulb();
const led = new LEDLight();

const switch1 = new Switch(bulb);
switch1.operate(); // Output: "LightBulb is ON"

const switch2 = new Switch(led);
switch2.operate(); // Output: "LED Light is ON"

🚀 Advantages:
- Switch no longer depends directly on the LightBulb class, but instead depends on the Switchable interface.
- No need to change the Switch code to add LEDLight or other device.
- The code has become more flexible and extensible.

How Can We Use DeepSeek R1 LLM On Our Local Machine?

ugurgunes95 — Mon, 27 Jan 2025 15:11:32 +0000

In this article I'm going to cover how we can use the DeepSeek R1 Large Language Model on our local machine.
We will be using the Ollama command line tool to interact with the model.
We also will be using Anything LLM for better user experience.

Prerequisites

Make sure that you have Ollama installed on your local machine.
Make sure that you have Anything LLM installed on your local machine.

Installation

Once you've downloaded those links listed above;

Install Ollama.
Install Anything LLM.
These steps are pretty straightforward and should be done in a few minutes.

Downloading The Model

If you have installed Ollama correctly you just need to open a terminal and type the following command:
ollama run deepseek-r1:7b
This will download the model and start it on your local machine.
Once the model is downloaded and started, you can interact with it on terminal.

Adding The Model To Anything LLM

As you can see you are already able to use the model from Ollama command line tool.
But if you want a better user experience, you can add the model to Anything LLM. In this section I'll try to explain this.
Open Anything LLM and click New Workspace button.
This will create a new workspace and you will be able to customize it.
Then you need to click this little gear icon on the right of the workspace name.
From that screen, you should open Chat Settings and at the of this seciton you are going to see Workspace LLM Provider.
Once you have selected Ollama from that list you will see your downloaded model listed there.
You can then select it as your default model for the workspace and click update workspace at the end of the page.
Since this is not a how to guide for Anything LLM, I will leave you with this.
Now you can interact with your model in a more user-friendly way as you can see below.

Conclusion

In this section, we have learned how to add a downloaded model to Anything LLM and use it for better user experience. We have also seen how to customize the workspace and select the default model for the workspace.

React JS Conditional Routing Logic Implementation

ugurgunes95 — Thu, 14 Mar 2024 17:32:04 +0000

React JS Conditional Routing Logic Implementation

Setup

First things first we need to create our basic react application. In order to do that, open a terminal in a preferred location on your pc and run this command: npm create vite@latest.

Note that; in this example I have used vite. But you can also use create-react-app etc.

After the command above it will ask you for a project name, framework and variant. I am going to use TypeScript React template.
When you've created the project run this command to all the install dependencies and react-router;

  npm install && npm install react-router-dom@latest

or if you're using yarn;

  yarn install && yarn add react-router-dom@latest

Now I am going to delete unnecessary files etc. At the end of the setup section your file tree will look like this:

  ugur@gunes:~/Development/reactjs/test$ tree --dirsfirst
  .
  ├── public
  ├── src
  │   ├── index.css
  │   ├── Layout.tsx
  │   ├── main.tsx
  │   └── vite-env.d.ts
  ├── index.html
  ├── package.json
  ├── tsconfig.json
  ├── tsconfig.node.json
  └── vite.config.ts

  3 directories, 9 files

That's it for our basic setup.

Configuration

So let's create our pages which we're going to use in the next steps.

Creating Pages

I'll create a directory named pages in src folder. And inside of that directory I'll also create two other directories just to make the situation more clear.
I am creating AuthorizedPages and UnauthorizedPages directories in the src/pages folder.
And I will just create two components; one for AuthorizedPages(Home.tsx) and one for UnauthorizedPages(Login.tsx).

  // Home.tsx

  import { useContext } from "react";
  import { AuthContext } from "../../context/AuthContext.tsx";

  const Home = () => {
    const { setLoginContext } = useContext(AuthContext);
    return (
      <section>
        <h1>Home Page</h1>
        <button onClick={() => setLoginContext(false)}>Logout</button>
      </section>
    );
  };

  export default Home;

  // Login.tsx

  import { useContext } from "react";
  import { AuthContext } from "../../context/AuthContext.tsx";

  const Login = () => {
    const { setLoginContext } = useContext(AuthContext);
    return (
      <section>
        <h1>Login Page</h1>
        <button onClick={() => setLoginContext(true)}>Login</button>
      </section>
    );
  };

  export default Login;

Here's how it looks at the end:

  .
  ├── public
  ├── src
  │   ├── pages
  │   │   ├── AuthorizedPages
  │   │   │   └── Home.tsx
  │   │   └── UnauthorizedPages
  │   │       └── Login.tsx
  │   ├── index.css
  │   ├── Layout.tsx
  │   ├── main.tsx
  │   └── vite-env.d.ts
  ├── index.html
  ├── package.json
  ├── tsconfig.json
  ├── tsconfig.node.json
  └── vite.config.ts

  6 directories, 11 files

Check the page files' content on the github repository.

Creating AuthContext

In this section we'll create AuthContext. I will not implement authentication logic to make this article short and less complicated. Instead we'll just simulate it.

I am creating a directory called context under our src folder.
In this directory we'll create 4 files: AuthContext.tsx, AuthContextType.tsx, AuthContextProviderPropType.tsx and AuthContextInitialState.tsx.
Creating 4 different files is not necessary but I just like to seperate them.
File's contents will be like that:

  // AuthContext.tsx

  import { createContext, useState } from "react";
  import { AuthContextType } from "./AuthContextType.tsx";
  import { AuthContextInitialState } from "./AuthContextInitialState.tsx";
  import { AuthContextProviderPropType } from "./AuthContextProviderPropType.tsx";

  export const AuthContext = createContext<AuthContextType>(
  AuthContextInitialState,
  );

  export const AuthContextProvider = ({
  children,
  }: AuthContextProviderPropType) => {
  const [isLoggedIn, setIsLoggedIn] = useState<boolean>(false);
  const [loading, setLoading] = useState<boolean>(false);
  const setLoginContext = (status: boolean = false) => {
      // simulate login logic
      setLoading(true);
      setTimeout(() => {
      setIsLoggedIn(status);
      setLoading(false);
      }, 1500);
  };
  return (
      <AuthContext.Provider value={{ loading, isLoggedIn, setLoginContext }}>
      {children}
      </AuthContext.Provider>
  );
  };

  // AuthContextType.tsx

  export interface AuthContextType {
    loading: boolean;
    isLoggedIn: boolean;
    setLoginContext: (status: boolean) => void;
  }

  // AuthContextProviderPropType.tsx
  import React from "react";

  export interface AuthContextProviderPropType {
    children: React.ReactNode;
  }

  // AuthContextInitialState.tsx
  import { AuthContextType } from "./AuthContextType.tsx";

  export const AuthContextInitialState: AuthContextType = {
    loading: false,
    isLoggedIn: false,
    setLoginContext: () => {},
  };

The end of context setup... it's pretty straight forward stuff.

Creating Routing Files

Now it's time to create routing part. As I said before I like to keep files seperately. Let's create our routing files. In order to do that I'll create 1 directory and 3 files in it.

Create routing directory under the src folder.
In the routing folder create 3 files and name them as you wish. I'll name them; AuthorizedRoutes.tsx, UnAuthorizedRoutes.tsx and BaseRouting.tsx.
Let's now create the content for theses files:

  // AuthorizedRoutes.tsx
  import { RouteObject } from "react-router-dom";
  import Home from "../pages/authorized-pages/Home.tsx";

  const AuthorizedRoutes: RouteObject[] = [
    {
      path: "",
      element: <Home />,
    },
    {
      path: "home",
      element: <Home />,
    },
  ];

  export default AuthorizedRoutes;

  // UnAuthorizedRoutes.tsx
  import { RouteObject } from "react-router-dom";
  import Login from "../pages/unauthorized-pages/Login.tsx";

  const UnAuthorizedRoutes: RouteObject[] = [
    {
      path: "",
      element: <Login />,
    },
    {
      path: "login",
      element: <Login />,
    },
  ];

  export default UnAuthorizedRoutes;

  // BaseRouting.tsx
  import { createBrowserRouter, RouterProvider } from "react-router-dom";
  import Layout from "../components/Layout.tsx";
  import { useContext } from "react";
  import { AuthContext } from "../context/AuthContext.tsx";
  import AuthorizedRoutes from "./AuthorizedRoutes.tsx";
  import UnAuthorizedRoutes from "./UnAuthorizedRoutes.tsx";
  import ErrorComponent from "../components/ErrorComponent.tsx";

  const RoutingProvider = () => {
    const { isLoggedIn } = useContext(AuthContext);
    const router = createBrowserRouter([
      {
        path: "/",
        element: <Layout />,
        errorElement: <ErrorComponent />,
        children: isLoggedIn ? [...AuthorizedRoutes] : [...UnAuthorizedRoutes],
      },
    ]);

    return <RouterProvider router={router} />;
  };

  export default RoutingProvider;

What we did? Let's review...
BaseRouting.tsx file is our main routing file. Inside of that we have our Layout component which is like wrapper for our app.
But the children of our main route is depends to the isLoggedIn state which we've created in out context part.
If there is a logged in user; we'll render the app with routes requires authorization, if there isn't we'll render the app with unauthorized routes.
This way we're also make Login route not accessible if user is logged in.

Configure Our Main.ts File

We need to apply those to our app:

  // main.tsx
  import ReactDOM from "react-dom/client";
  import "./index.css";
  import { AuthContextProvider } from "./context/AuthContext.tsx";
  import RoutingProvider from "./routing/BaseRouting.tsx";

  ReactDOM.createRoot(document.getElementById("root")!).render(
    <AuthContextProvider>
      <RoutingProvider />
    </AuthContextProvider>,
  );

Conclusion

That's it. I am not exactly sure if this approach is convenient, but I am pretty sure that I'll use it in my next projects. Hope it helps you people.

Github Repo