DEV Community: Ram kumar Shrestha

[Boost]

Ram kumar Shrestha — Tue, 11 Feb 2025 05:23:26 +0000

TypeORM Eager - Don't fall for it

Ram kumar Shrestha ・ Feb 11

TypeORM Eager - Don't fall for it

Ram kumar Shrestha — Tue, 11 Feb 2025 05:23:16 +0000

Typeorm is very helpful tool when working with PostgreSQL. It has many built in features to help the developers. Among all of those features eager is one of them.

eager relations are loaded automatically each time you load entities from the database. For example, when Test is loaded the items table will be automatically joined and populated.

@Entity()
export class Test{
   @PrimaryGeneratedColumn('uuid')
   id: string;

   @OneToMany(() => TestItem, (item) => item.test, { eager: true })
   items: Array<TestItem>;
}

It seems fun only if it is totally independent from other entities. But when the Test entity itself is joined to other entities then problem occurs.

Here are few downfall of using eager:

Memory overload when the Test has too many items
As earlier said if its joint in other tables/entities where items is not needed, then in that case we can not disable eager loading of items which is redundant.
It always makes sures to load items or (eager loaded other relation) even for simple queries.
Performance issue as the eager always loads all linked relations.
Might cause maximum call stack memory exceeded error.
Developers might forget the eager has been used and use extra relations on typeorm query or join table on query builder.
Might go to infinite circular dependencies as below:

@Entity()
class TestItem {
   @ManyToOne(() => Test, (test) => test.items, { eager: true })
   test: Test;
}

Here Test tries to eager load TestItem and vice versa which will cause circular dependencies.

Solution

Only load the relations whenever needed as:

Use relations with typeorm

await Test.find({ 
  relations: ['items']
});

Use join with query builder

await Test.createQueryBuilder('test')
         .leftJoinAndSelect('test.items', 'items')
         .getMany();

Have you ever used eager and forgot that you have used and just go with relations causing eventually the tragedy of performance loading???

What is this?

Ram kumar Shrestha — Sat, 08 Feb 2025 03:04:30 +0000

What is THIS ?

Ram kumar Shrestha ・ Feb 8

#javascript #frontend #programming #interviewtips

What is THIS ?

Ram kumar Shrestha — Sat, 08 Feb 2025 02:57:02 +0000

JavaScript the most popular programming language in the world. Almost every developer has been using JavaScript for various purposes from web app, mobile app, scripting to desktop app etc. JavaScript is so simple yet it can do almost everything.

One of the most confusing topic ever in JavaScript is this. this keyword sound so simple but I found many developers confused while using it.

Introduction

The this keyword refers to the context where a piece of code, such as a function's body, is supposed to run.

It severely depends on the runtime binding i.e, how its being invoked rather. Its value depends upon the context it appears.

Cases

Global

When this is used standalone i.e, directly on the code not inside any scope then usually it gives the global object (in non-strict mode) while its undefined in strict mode.

Class

If this is inside the class context then its value will be the class instance itself whether its on constructor or in any methods.

class ThisCalss{
   name = "ThisClass"
    constructor() {
      console.log(this.name) // "ThisClass" upon instace creation
   }

   printName() {
       console.log(this.name) // "ThisClass upon method invocation
   }
}

Arrow Function

Arrow functions' this value depends on the enclosing lexical context's this.

const printName = () => {
     console.log(this.name);
};

Result : As the printName is directly under global lexical scope the console will print undefined.

class ArrowExample {
  name = "ArrowExample";

  printName() {
    setTimeout(() => {
      console.log(this.name);  
    }, 100);
  }
 }

 const arrow = new ArrowExample();
 arrow.printName();

Result: Here arrow function lexical scope is ArrowExample class so the output will be ArrowExample (value of name).

Conventional Function

In conventional functions (functions declared with the function keyword), this is determined by how the function is called, not where it's defined. The value of this depends on the calling context.

 function showThis() {
   console.log(this);
 }

 // Called directly
 showThis(); // window (in non-strict mode) or undefined (in strict mode)

 // As an object method
 const obj = {
    name: 'Object',
    show: showThis
 };
 obj.show(); // {name: 'Object', show: ƒ}

 // Using new keyword
 new showThis(); // showThis {}

Object Inside object's method the this value is object itself.

 const laptop = {
     brand: 'Apple',
     getBrand: function() {
         return this.brand;
     }   
 }
console.log(laptop.getBrand()) // 'Apple'

Passing this context

We can control the this context value with the help of bind, apply, call.

The bind, call directly invokes methods/functions with the this context value. The only difference between them is the second parameters. apply accepts comma separated value while call accepts the array in second parameter.

 function getThis() {
   return this;
 }   

 console.log(getThis.apply('this apply')) // 'this apply'

 console.log(getThis.call('this apply 2'))  // 'this apply 2'

While bind will only create new reference of the function/method it will not be invoked. This bind is very helpful iff we have to pass the function as parameter to any other function/methods.

 function getThis() {
     return this;
 }   

 const newRef = getThis.bind('this bind');
 console.log(getThis()); // undefined
 console.log(newRef()); // this bind

Conclusion

Understanding this in JavaScript requires careful attention to the context in which it's used. Here are the key points to remember:

The value of this is determined by how a function is called (runtime binding)
Class methods and object methods naturally bind this to their instance/object
Arrow functions inherit this from their enclosing scope
Conventional functions can have different this values based on their calling context
bind, call, and apply provide ways to explicitly control this binding

Being mindful of these rules will help you avoid common pitfalls and use this effectively in your JavaScript code.

PostgreSQL Sorting - Not Simple as "You would think"

Ram kumar Shrestha — Sat, 01 Feb 2025 02:13:51 +0000

Accessing database collections and displaying the result is a peace of cake with various techniques. Users often need to sort the data according to their different need (for e.g. date). For that purpose PostgreSQL's default sort works as expected. However, when user attempts to sort the column that has numbers stored as string then things go wrong, the default sort gives unexpected results due to lexicographical sorting.

Lexicographical Order

The way data (like strings or numbers) is sorted in a "dictionary order," meaning characters are compared one by one, from left to right, just like how words are arranged in a dictionary, with the first character determining the order if the initial characters are the same.

Simply put PostgreSQL compares the words/values, stored as string (whether it is number or actual string) of the columns, from left to right based on their ASCII code or Unicode values. However it works on normal cases for strings but it won't work as expected in case of the number as strings.

It is a case-sensitive sorting algorithm. Uppercase letters are considered smaller than lowercase letters.

Example

Consider a persons table with a name and age column, where age is stored as a string:

name     | age
---------|---------
'ram'    | '16'
'hari'   | '7'
'sita'   | '20'
'rita'   | '1'
'ashok'  | '104'
'prabin' | '2'

SELECT name FROM persons ORDER BY name ASC;

Result

'ashok'
'hari'
'prabin'
'ram'
'rita'
'sita'

Excellent the output is as expected, now lets' see an example for sorting of age which is stored as string.

SELECT age FROM persons ORDER BY age ASC;

Result

'1'
'104'
'16'
'2'
'20'
'7'

This is not what user expected but the according to the default PostgreSQL's behavior this is correct.

Solutions for Sorting of Numerical String

Type Casting: Casting the value to numbers before sorting makes sure it sorts the numbers as numbers rather than sorting string.

SELECT age FROM persons ORDER BY age::INTEGER ASC;

--or 

SELECT age FROM persons ORDER BY CAST(age AS INTEGER) ASC;

Result

'1'
'2'
'7'
'16'
'20'
'104'

This is the correct result as user expected.

✅ Ensures correct numerical order, fast execution.
❌ Fails if non-numeric values exist.

Zero Prefix Padding: As we know normally people lives for 100 to 125 years old at max so, what we need to do is make sure the age is always three digits. For that purpose we use 0s before the values if those are not 3digits. The values should be stored by padding already if not we can use following query to simulate padding.

-- Here LPAD means left padding
SELECT age FROM persons ORDER BY LPAD(age, 3, '0') ASC;

Padding Preprocessed columns

'1'   → '001'
'2'   → '002'
'7'   → '007'
'16'  → '016'
'20'  → '020'
'104' → '104'

Result

'1'
'2'
'7'
'16'
'20'
'104'

✅ Works with strings, maintains consistency
❌ Needs proper length padding

However lexicographical ordering works for following purposes as normal without any thoughts.

String sorting algorithms.
Searching for words in dictionaries.
Comparing filenames, usernames, or keys in databases.
Competitive programming challenges requiring string comparisons.

Conclusion

Lexicographical ordering plays a crucial role in string sorting but can cause issues when dealing with numeric strings. While *PostgreSQL’s * default behavior follows lexicographical order, proper handling of numeric strings requires explicit type casting or padding techniques. By understanding and applying these solutions, developers can ensure accurate and expected sorting behavior in their applications.

Have you faced similar sorting challenges? Share your experiences in the comments!

Intersection Observer API: A Hidden Gem in JavaScript

Ram kumar Shrestha — Sun, 19 Jan 2025 14:12:02 +0000

Recently while exploring the frontend world, I came upon a interesting feature of JavaScript -> Intersection Observer. Intersection Observer API is one of the most underutilized and unheard JavaScript's features.

Intro

The Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document's viewport.
However its sounds complex but it provides a simple solution for the most general problem: knowing when an element becomes visible of invisible to the use.

Why It Matters

scroll event was the go-to method for developers when it comes to determine whether an element is visible on screen. Developers often had to perform manual calculations optimizations to ensure performance remained optimal, especially when tracking several elements. This approach could become inefficient while tracking several elements as the browser repeatedly recalculated positions during scrolling.

How It Works

The Intersection Observer basically revolves around three components:

Observer: The _IntersectionObserver _object watches one or more elements.
Callback: A function is triggered whenever the visibility of a target element changes.
Options: Configuration parameters like root, rootMargin, and threshold.

root: Defines viewport for checking visibility. The default value is null which refers to browser;s viewport.
rootMargin: A margin around the root element, similar to CSS margin. Positive value grows/adds while negative value shrinks/subtracts the bounding box of the root element.
threshold : Specifies the percentage of the target element’s visibility that must be reached before the observer’s callback is triggered. It ranges from 0 (0%) to 1 (100%)

Implementation

To get started, create an instance of IntersectionObserver

  const lazyObserver = new IntersectionObserver(handleLazyImage, {
    rootMargin: "-10px", //10px margin was used in the container to address that margin
    root: lazyImageContainer, // Custom container as the root
    threshold: 0.25, // Trigger when 10% of the image is visible in the container
  });

In the example above, handleLazyImage is callback function while the remaining properties are config options.

After the observer is instantiated, simply start observing the target elements:

  lazyImages.forEach((img) => lazyObserver.observe(img));

For more details, you can checkout theGithub repository.

Practical Use cases

Infinite Scrolling: Detect when the user reaches the end of the page and fetch new data via API calls.
Lazy Loading: Load images or other content as they come into view during scrolling.
Ad Visibility Reporting: Track whether advertisements are visible to users to calculate ad revenue.
Task and Animation Control: Trigger tasks or animations only when the user is likely to see the results, improving performance and user experience.

Conclusion

The Intersection Observer API represents a significant step forward in how we handle viewport-based interactions in web applications. It provides a clean, efficient solution for many common use cases while improving performance and reducing complexity. Whether you're implementing lazy loading, infinite scrolling, or scroll-based animations, the Intersection Observer API should be your go-to tool.

Give it a try in your next project - your users (and your performance metrics) will thank you!

Switching Modes: Implementing a Light-Dark Theme by CSS Only 🌗

Ram kumar Shrestha — Fri, 22 Nov 2024 11:00:17 +0000

Switching between light and dark themes has become a must-have feature for modern websites, as most users prefer having control over their viewing preferences. This small yet impactful addition can significantly enhance usability, aesthetics, and overall user experience.

In this blog, we’ll explore how to implement a light-dark theme toggle using CSS and JavaScript, ensuring both accessibility and a seamless experience for your users.

Why Light-Dark Themes?

User Preferences: Mos users prefer dark themes to reduce eye strain, especially in low-light environments.
Aesthetic Appeal: A well-designed dark theme adds a modern touch to your website.
Device Compatibility: Many devices now support dark mode natively, and websites can complement this feature.

CSS's Powerful Light-Dark Property

CSS introduced a powerful property light-dark to simplify theme toggling. In this blog, we’ll explore how to use it with a straightforward example.

Example

Simple HTML structure The first step is provide a button which will toggle the theme in the web browser.

<body id="content">
  <button id="theme-toggle">Switch Theme</button>
</body>

Here, clicking the button will toggle the theme.

Provide the CSS for theme toggle

#content {
   background-color: light-dark(#eeee, #424242);
}

Here, #eee will be the background color for light theme and #424242 will be for the dark theme.

Script to toggle the theme

const themeToggle = document.getElementById("theme-toggle");

themeToggle.addEventListener("click", () => {
  const content = document.getElementById("content");
  const currentTheme = content.style["color-scheme"];

 content.style["color-scheme"] = currentTheme === "dark" ? "light" : "dark";
});

When the theme-toggle button is clicked, the script toggles the theme between light and dark modes dynamically.

Conclusion

Implementing a light-dark theme toggle is an essential feature for enhancing user experience and aligning with modern design trends. By leveraging the power of CSS and JavaScript, you can create an accessible, visually appealing, and user-friendly theme toggle for your website.

With this feature, you not only accommodate users’ preferences but also ensure compatibility with devices that support native dark modes. Adding a light-dark theme toggle is a small but meaningful step toward creating a more versatile and inclusive web experience.

Why You Shouldn’t Use Libraries Blindly: A Lesson in Bundle Size

Ram kumar Shrestha — Thu, 14 Nov 2024 10:08:12 +0000

When developing any web applications, the instinctive choice is to reach for popular libraries that solve our specific problem quickly. However, while libraries can save time, it’s essential to carefully evaluate their impact on the final product. One often overlooked factor is bundle size, which can significantly affect your application’s performance, especially for end-users with limited internet speed.

The Issue: Too Big Bundle Sizes

Each third-party library you add to a project contributes to the overall size of your application’s bundle. Large bundles can slow down page load times, leading to poor user experience and lower SEO rankings. This issue becomes more evident when libraries include more functionality than you need. Initially, you may think what if our bundle size increases by just some MB. But, that will cost a lot in page load time.

Real-World Example: The country-state-city Library

Let's say we’re building a simple form with dropdowns for selecting a user’s address. At first glance, country-state-city seems like an ideal choice — it’s popular, covers all the data you need, and is ready to go. However, on closer inspection, it brings along a hefty payload, as it includes an extensive database of countries, states, and cities worldwide all in frontend only.

For instance:

Bundle Bloat: country-state-city brings all three datasets: countries, states, and cities, and with a great cost its about 10MB+ in size which will be much more big than app itself.
Stale Data: While the country-state-city library offers a comprehensive dataset, it’s not always up-to-date. For example, in Nepal, administrative divisions have shifted from development regions to provinces. However, country-state-city still organizes Nepal’s data according to the outdated development regions. Relying on such a library can lead to inconsistencies, as users may encounter data that doesn’t align with current administrative structures. Loading this extra data could negatively affect your app’s performance, and ultimately, the user experience.

The Solution: Create a Custom API

Instead of using a library that doesn't meet client's expectations, consider creating a custom API that serves the data your application requires. In this example, building a backend API for this will completely remove the oversized library. Here are a few reasons why:

Reduced Bundle Size: Custom APIs removes the oversized library form frontend totally, reducing load times and improving responsiveness.
Better Performance: Custom APIs offer faster response times because they process smaller requests and return only the required information.
Enhanced Control: With a custom API, you’re in control of the data’s structure and format, allowing you to modify it as your app evolves.

Steps to Build Your Own API for Country and State Data

Here’s a quick outline for building your own API:

Define the Requirements: Identify the data scope—perhaps only a limited set of countries and states, the country-state-city itself can be used as great inspiration and reference.
Data Source: Use a reliable open-source dataset or an external API to populate your database.
Build the API: Create a simple REST API endpoint to serve this data.
Optimize for Performance: Cache frequently requested data and use efficient database queries.
Integrate with the App: Fetch only the data you need from this custom API, rather than an entire library.

Key Takeaway: Assess Before You Install

While it can be tempting to use libraries for their convenience, it’s essential to consider the implications carefully:

Evaluate Bundle Impact: Before adding a library, check the impact on bundle size.
Consider Long-Term Maintenance: Additional libraries introduce dependencies, which require updates and maintenance.
Check for Unused Features: Look for ways to use only the parts you need or alternatives to avoid excess data.

By taking the time to assess each library and evaluating alternative solutions like custom APIs, you can improve performance and ensure your app remains light and user-friendly. Libraries can be great tools, but they aren’t a one-size-fits-all solution—use them wisely to strike the right balance between convenience and efficiency.

💡 Database Development: It’s Not Just About Querying!

Ram kumar Shrestha — Tue, 12 Nov 2024 12:12:18 +0000

As backend/database engineers, we often think of databases as places to store and retrieve data. But sometimes, with a bit of exploration, we realize they can do much more.

Recently, I faced a unique requirement in my project with PostgreSQL: after inserting a row into public.test_table, every existing row in that same table needed to be updated to reflect the new information.

Initial Approach

At first, my instinct was to handle this logic in the backend, creating a method in the NestJS service layer to process each row update. But then I paused and thought: could PostgreSQL handle this independently?

A bit of research later, I found the answer: Yes, with triggers! By leveraging PostgreSQL triggers and functions, we can move this logic directly to the database, improving both performance and maintainability.

The Solution: PostgreSQL Trigger and Function

Using a trigger to automate updates means that every time a row is inserted, PostgreSQL takes over and runs the update logic on all rows.

Here’s the process:

Define a function in PostgreSQL to specify the logic applied to all rows.
Create a trigger that executes this function after every insert on public.test_table.

Example Code

Here’s a simplified example of what this looks like in PostgreSQL :

-- Step 1: Create a function that updates all rows in the table
CREATE OR REPLACE FUNCTION update_all_rows() 
RETURNS TRIGGER AS $$
BEGIN
    -- Custom logic applied to all rows; here’s a simple example
    UPDATE public.test_table
    SET column_name = NEW.column_name;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Step 2: Create a trigger that calls the function after every insert
CREATE TRIGGER after_insert_trigger
AFTER INSERT ON public.test_table
FOR EACH ROW EXECUTE FUNCTION update_all_rows();

Including in a Migration File

For consistency across environments, adding this code to a migration file ensures it is applied automatically in each deployment. Here’s a sample migration file using TypeORM:

import { MigrationInterface, QueryRunner } from "typeorm";

export class AddUpdateAllRowsTriggerToTestTable implements MigrationInterface {
    public async up(queryRunner: QueryRunner): Promise<void> {
        await queryRunner.query(`
            CREATE OR REPLACE FUNCTION update_all_rows() 
            RETURNS TRIGGER AS $$
            BEGIN
                UPDATE public.test_table
                SET column_name = NEW.column_name;
                RETURN NEW;
            END;
            $$ LANGUAGE plpgsql;

            CREATE TRIGGER after_insert_trigger
            AFTER INSERT ON public.test_table
            FOR EACH ROW EXECUTE FUNCTION update_all_rows();
        `);
    }

    public async down(queryRunner: QueryRunner): Promise<void> {
        await queryRunner.query(`
            DROP TRIGGER IF EXISTS after_insert_trigger ON public.test_table;
            DROP FUNCTION IF EXISTS update_all_rows;
        `);
    }
}

Key Benefits

Efficiency: Processing the logic directly within the database reduces network load and speeds up data handling.
Maintainability: Centralizing logic in the database means fewer lines of application code and a more maintainable backend.
Portability: Using a migration file ensures that this functionality is automatically set up in every environment.

Takeaway

This experience was a reminder of the untapped capabilities in PostgreSQL and the benefits of letting the database handle certain logic independently.

🚀 Have you ever found a creative solution by using database features to streamline your code? Let's share insights and learn from each other!

Optimizing Error Handling: Reducing Redundant Try-Catch Blocks

Ram kumar Shrestha — Tue, 24 Sep 2024 07:35:06 +0000

In any application, error handling is critical to maintain stability and reliability. Typically, a common way to handle errors is by using try-catch blocks. While effective, this approach can clutter the code, make it less DRY, decrease readability, and complicate maintenance.

In this post, we will explore a more efficient way to handle errors in a TypeScript OOP-based application using NestJS by leveraging decorators.

The Problem with try-catch Blocks

Code Duplication: As the number of methods increases in a class, duplicating the same try-catch blocks across various methods becomes inefficient and harder to manage.
Reduced Readability: Nesting try-catch blocks leads to nested code blocks, which can make the code more difficult to read and understand.
Poor Exception Propagation: If exceptions are caught too early, they may not propagate to higher layers of the application where they can be handled more appropriately, missing opportunities for centralized error handling.

The Solution: Using Decorators for Error Handling

Instead of repeating try-catch blocks, we can centralize error handling using decorators. This approach keeps the code cleaner, more readable, and easier to maintain.

In NestJS, we can use decorators to intercept method calls and handle errors globally across services. Let's see how we can achieve this.

Step 1: Defining the Error Handling Decorator
Here's how we can create a decorator to handle errors in methods:

This decorator wraps the method execution in a try-catch block.
Any error caught is logged, and an RpcException is thrown to signal an error in a gRPC-based service.
Note: This example uses RpcException, which is specific to gRPC microservices. If you're not using gRPC, you can replace it with an appropriate exception type (e.g., HttpException for HTTP-based services).

Step 2: Using the Decorator in Services
Once the decorator is defined, you can apply it to any service method that needs centralized error handling:

By adding @HandleErrors() above a method, you ensure that any error occurring within that method will be caught by the decorator and handled appropriately.

Conclusion

By adopting decorators for error handling, you can reduce the number of redundant try-catch blocks in your code, making it cleaner, more readable, and easier to maintain.

Centralizing error handling through decorators helps you:

Keep your code DRY (Don't Repeat Yourself).
Handle exceptions more systematically.
Improve readability and reduce clutter in methods.

In summary, this approach allows you to manage errors more efficiently by handling them at the right level and letting exceptions propagate when necessary. This makes debugging and maintaining your code much simpler.