DEV Community: Muhammad A Faishal

JavaScript `string.replace()` useful cases

Muhammad A Faishal — Fri, 13 Sep 2024 13:59:28 +0000

1. Simple String Replacement

Replace the first occurrence of a substring.

let str = "Hello world!";
let result = str.replace("world", "JavaScript");

// Output: "Hello JavaScript!"

2. Global String Replacement

Replace all occurrences of a substring, use the global (g) flag with regular expression.

let str = "Hello world, world!";
let result = str.replace(/world/g, "JavaScript");

// Output: "Hello JavaScript, JavaScript!"

3. Case-insensitive Replacement

You can make the replacement case-insensitive using the i flag.

let str = "Hello World, World!";
let result = str.replace(/world/gi, "JavaScript")

// Output: "Hello JavaScript, JavaScript!"

4. Replace Whole Words (Word Boundary)

Replace only whole words using \b word boundary.

let str = "This is a test word, test.";
let result = str.replace(/\btest\b/, "success");

// Output: "This is a success word, test."

Replace all occurrences of the whole word, use the global flag.

let str = "This is a test word, test.";
let result = str.replace(/\btest\b/g, "success");

// Output: "This is a success word, success."

5. Using a Function for Replacement

You can pass a function to replace() that dynamically generates the replacement string.

let str = "The price is $10";
let result = str.replace(/\$\d+/g, (match) => {
   return `$${parseInt(match.substring(1)) * 2}`
});

// Output: "The price is $20"

6. Capturing Groups with Replacement

Using regular expressions, you can capture parts of the match and reuse them in the replacement string.

let str = "John Smith";
let result = str.replace(/(\w+)\s(\w+)/, "$2, $1");

// Output: "Smith, John"

7. Escaping Special Characters

If you need to replace special characters like . or *, you need to escape them in the regular expression.

let str = "Price: 5.99";
let result = str.replace(/\./, ",");

// Output: "Price: 5,99"

8. Replacing Non-ASCII Characters

To replace characters that aren't in the ASCII range, you can use Unicode properties.

let str = "Héllo Wörld";
let result = str.replace(/[^\x00-\x7F]/g, "");

// Output: "Hllo Wrld"

9. Replacing Digits

You can replace digits (or groups of digits) using regular expressions.

let str = "Contact: 123-456-7890";
let result = str.replace(/\d{3}/g, "***");

// Output: "Contact: ***-***-***0"

10. Replacing Special Characters using Unicode

You can also use Unicode escape sequences to replace special characters.

let str = "I love ☕!";
let result = str.replace(/\u2615/g, "coffee"); 

// Output: "I love coffee!"

11. Replace Words using Lookbehind and Lookahead assertion

Replace only whole words while preserving the surrounding whitespace.

let str = "This is a test word, test.";
let result = str.replace(/(?<=\s|^)test(?=\s|$)/, "success");

// Output: "This is a success word, test."

Replace all occurrences of the whole word, use the global flag.

let str = "This is a test word, test.";
let result = str.replace(/(?<=\s|^)test(?=\s|$)/g, "success");

// Output: "This is a success word, test."

Use "@ts-expect-error" over "@ts-ignore" in TypeScript

Muhammad A Faishal — Mon, 25 Sep 2023 13:41:57 +0000

TypeScript provides several directive comments which allow you to suppress TypeScript compiler errors. The directive comments supported by TypeScript are:

To ignore errors on specific lines
// @ts-expect-error
// @ts-ignore

To skip checking some files
// @ts-nocheck

To enable errors
// @ts-check

Have you wondered why TypeScript team bothers to provide 2 comments to ignore errors on particular lines?

Let's say we have a function called sum that adds numbers.

function sum(num1: string | number, num2: string) {
   return Number(num1) + Number(num2)
}

sum(1, 2)
// Triggering an error ❌
// Argument of type 'number' is not assignable to parameter of type 'string'.ts(2345)

When you don't have time to fix the error right away because the code is working fine in runtime, you decide to use @ts-ignore to ignore the type error.

function sum(num1: string | number, num2: string) {
   return Number(num1) + Number(num2)
}

// @ts-ignore
sum(1, 2)

The following day, you discover that the type of num2 should be string | number, like num1, rather than just a string.

function sum(num1: string | number, num2: string | number) {
   return Number(num1) + Number(num2)
}

// @ts-ignore
sum(1, 2)

Here's the risky part. When you use @ts-ignore, you're breaking the type safety of the code. Even though your code is working fine, the type checking is ignored.

That's why TypeScript team provides another directive comment to ignore the type error. It's @ts-expect-error.

Now, let's go back to the previous error, when num2 type is only string and we use @ts-expect-error instead of @ts-ignore.

function sum(num1: string | number, num2: string) {
   return Number(num1) + Number(num2)
}

// @ts-expect-error
sum(1, 2)

After num2 type is fixed, it will trigger an error that says Unused '@ts-expect-error' directive.. This means that the type is already correct and there's no need to ignore the type error anymore.

You can remove the @ts-expect-error.

function sum(num1: string | number, num2: string | number) {
   return Number(num1) + Number(num2)
}

// @ts-expect-error
sum(1, 2)
// Triggering an error ❌
// Unused '@ts-expect-error' directive. ts(2578)

Conclusion

Sometimes, developers face situations where they need to complete a task / project quickly, even if it means compromising the quality of the code, like ensuring proper typing in TypeScript. This often leads to developers temporarily ignoring type errors using @ts-ignore with the intention of fixing them later. But, this approach can lead to bigger issues in the future.

This is why TypeScript team provides another directive comment known as @ts-expect-error. Unlike @ts-ignore, it doesn't completely ignore the type error.

Bonus

You can install @typescript-eslint and enable one the rules named prefer-ts-expect-error (https://typescript-eslint.io/rules/prefer-ts-expect-error).

The rule will automatically replace @ts-ignore to @ts-expect-error.

// @ts-ignore ❌
sum(1, 2)

// @ts-expect-error ✅
sum(1, 2)

Better Git Commits with `@commitlint`

Muhammad A Faishal — Mon, 11 Sep 2023 12:09:21 +0000

When working on a project together, Git is a crucial tool that help teams collaborate smoothly. One of the key features is commits, which act like snapshots of the project's progress.

However, do you know which one of my commit add a new feature? I'm sure you won't, including me...

The problem is I was naming the commit randomly without looking at the context which makes it harder for me to identify when I want to revert the changes.

To solve the problem, there is a useful linter named commitlint. It will prevent us from naming our commits randomly

// git commit
git commit -m "oops"

// it will trigger this error 
// ❌ type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]

and force us to name the commit properly.

git commit -m "fix: resolve the issue related to comma"
git commit -m "feat: add a feature named calculator"

It's very clear and easy to understand the context, right?

The following are all the types that commitlint suggests and provides including the example commit:

build --> Changes that affect the build system or external dependencies

git commit -m "build: update npm dependency"

ci --> Changes to our CI configuration files and scripts

git commit -m "ci: add circleci configuration file"

docs --> Documentation only changes

git commit -m "docs: update readme with installation instructions"

feat --> A new feature

git commit -m "feat: add user authentication feature"

fix --> A bug fix

git commit -m "fix: resolve issue with incorrect data rendering"

perf --> A code change that improves performance

git commit -m "perf: optimize database query for faster response times"

refactor --> A code change that neither fixes a bug nor adds a feature

git commit -m "refactor: reorganize code structure for better readability"

style --> Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

git commit -m "style: format code according to Prettier standards"

test --> Adding missing tests or correcting existing tests

git commit -m "test: add unit tests for user authentication"

There are many features of commitlint that I can't mention one by one, as well as installation guide. To know the detail you can directly access https://github.com/conventional-changelog/commitlint.

You might not need TypeScript Enum

Muhammad A Faishal — Tue, 05 Sep 2023 14:25:58 +0000

In TypeScript, there is a feature called Enum which is not a type-level extension of JavaScript. Enums allow a developer to define a set of named constants.

enum EDirection {
  Up = "Up",
  Down = "Down",
  Left = "Left",
  Right = "Right",
}

// Using the enum as a parameter
function walk(dir: EDirection) {}

walk(EDirection.Left);

But, on the other hand, we may not need Enum as TypeScript team says on https://www.typescriptlang.org/docs/handbook/enums.html#objects-vs-enums by using an object with as const.

const ODirection = {
  Up: "Up",
  Down: "Down",
  Left: "Left",
  Right: "Right",
} as const;


type Direction = typeof ODirection[keyof typeof ODirection];

function run(dir: Direction) {}

run(ODirection.Right);

So what's the difference between Enum and Object? I'll discuss the difference in Data Types, Bundle size, and How to use aspects.

Data Types

Enum

TypeScript provides both numeric and string-based enums.

// Numeric Enums
enum UserResponse {
  No = 0,
  Yes = 1,
}

// String Enums
enum UserResponse {
  No = "No",
  Yes = "Yes",
}

Constants

While Constants can cover an object with string and number property values including all data types.

// Number
const PI = 3.14159;

// String
const GREETING = "Hello, World!";

// Boolean
const IS_ACTIVE = true;

// Array
const COLORS = ["red", "green", "blue"];

// Object
const PERSON = {
    name: "John",
    age: 30
};

// RegExp
const EMAIL_PATTERN = /^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$/;

// Null
const NO_VALUE = null;

// Undefined
const UNDEFINED_VALUE = undefined;

// Symbol
const UNIQUE_KEY = Symbol("unique");

Transpiled Size

I used https://babeljs.io/repl to know the size after the code has been transpiled.

Enum

enum Color {
    Red = "RED",
    Green = "GREEN",
    Blue = "BLUE"
}

// Transpiled Result
var Color = /*#__PURE__*/function (Color) {
  Color["Red"] = "RED";
  Color["Green"] = "GREEN";
  Color["Blue"] = "BLUE";
  return Color;
}(Color || {});

// Size: 153 Bytes

Constants

const COLOR = {
    red: "RED",
    green: "GREEN",
    blue: "BLUE"
} as const;

// Transpiled Result
const COLOR = {
  red: "RED",
  green: "GREEN",
  blue: "BLUE"
};

// Size: 65 Bytes

How to use

An Enum named EDirection and an object named ODirection refer to the same thing as what we talked about earlier.

Enum

walk("Left");
// This shows an error ❌
// (Argument of type '"Left"' is not assignable to parameter of type 'EDirection')

walk(EDirection.Left);
// This works well ✅

Constant

run("Left");
// This works well ✅

run(ODirection.Left);
// This works well ✅

Conclusion

Based on several aspects I've discussed earlier, we can replace Enum with Object. Object has the flexibility for defining various data types, has a smaller transpiled size, and can detect both property values or property access.

So, it's important to remember that not all cool features are the best choice. Always assess the aspects you think important. If a feature doesn't have any negative impact, then you can confidently use it.

JavaScript CONSTANTS

Muhammad A Faishal — Sun, 03 Sep 2023 13:24:59 +0000

In JavaScript, most of developers are well-known with const. It declares block-scoped local variables which means the value of a constant can't be changed through reassignment using the assignment operator.

However, have you defined the constant properly and clearly?

Naming Convention

According to Airbnb Naming Uppercase, exported constants should follow SCREAMING_SNAKE_CASE format, but not for constants within a file.

// Within a file
const helloWorldText = "Hello, World!"

// Exported constants
export const HELLO_WORLD_TEXT = "Hello, World!"

Examples

The following are examples of all exported data type constants:

// Number
const PI = 3.14159;

// String
const GREETING = "Hello, World!";

// Boolean
const IS_ACTIVE = true;

// Array
const COLORS = ["red", "green", "blue"];

// Object
const PERSON = {
    name: "John",
    age: 30
};

// RegExp
const EMAIL_PATTERN = /^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$/;

// Null
const NO_VALUE = null;

// Undefined
const UNDEFINED_VALUE = undefined;

// Symbol
const UNIQUE_KEY = Symbol("unique");

Other uses

Besides defining data types, const is widely used in various other contexts.

a. Destructuring Arrays

const [a] = ["a"];

b. Destructuring Arrays with Default Values

const [a = 0] = [];

c. Destructuring Objects

const { a } = { a: "value" };

d. Destructuring Objects with Default Values

const { a = "default" } = {};

e. Global Constants

// Browser environment
window.GLOBAL_CONSTANT = "This is a global constant";

// Node.js environment
global.GLOBAL_CONSTANT = "This is a global constant";

f. Environment Variables (Node.js)

const PORT = process.env.PORT || 3000;

g. Template Literals with Constants

const name = "John";
const greeting = `Hello, ${name}!`;

h. Rest Parameters in Functions

function sum(...numbers) {
    const result = numbers.reduce((acc, num) => acc + num, 0);
    return result;
}

i. Destructuring Function Parameters

function printUser({ name, age }) {
    console.log(`Name: ${name}, Age: ${age}`);
}

j. Class Constants

class Circle {
    constructor(radius) {
        this.radius = radius;
    }

    getArea() {
        const PI = 3.14159;
        return PI * this.radius * this.radius;
    }
}

Serialization and Deserialization in JavaScript

Muhammad A Faishal — Wed, 02 Aug 2023 14:03:44 +0000

As developers, we often hear about Serialization and Deserialization, but what do these terms really mean?

Serialization

Serialization is the process of converting a data structure, such as JavaScript object or array, into a format that can be easily stored.

In JavaScript, the most common serialization format is JSON (JavaScript Object Notation). The JSON format is easy for both human and machine to read and write.

Example of serialization in JavaScript using JSON:

const data = { name: "John", age: 30 };

const jsonString = JSON.stringify(data);
// Output: '{"name":"John","age":30}'

Deserialization

Deserialization is the opposite process of Serialization. It converts data in its serialized format into its original data structure, such as a JavaScript object or array, to make the data usable and accessible in the application.

Example of deserialization in JavaScript using JSON:

const jsonString = '{"name":"John","age":30}';

const data = JSON.parse(jsonString);
// Output: { name: "John", age: 30 }

Other Formats

Not only JSON, there are numerous serialization formats available, as listed below:

BSON

BSON is a binary-encoded data interchange format designed to be more efficient in terms of storage and transmission compared to JSON. It extends JSON with additional data types and is typically used in the context of MongoDB.

Example of serialization & deserialization of BSON using bson package:

import { BSON, ObjectId } from 'bson';

const data = { _id: new ObjectId(), name: "John", age: 30 }

// serialization

const bytes = BSON.serialize(data);
// Output: <Buffer 2e 00 00 00 07 5f 69 64 00 64 ca 53 01 9d 14 77 b6 a1 a2 89 e4 02 6e 61 6d 65 00 05 00 00 00 4a 6f 68 6e 00 10 61 67 65 00 1e 00 00 00 00>

// deserialization

const doc = BSON.deserialize(bytes);
// Output: {
//  _id: new ObjectId("64ca53019d1477b6a1a289e4"),
//  name: 'John',
//  age: 30
// }

EJSON

Extended JSON (EJSON) is a superset of JSON, which means it includes all features of standard JSON and extends it additional conventions for representing certain data type and MongoDB specific constructs.

Example of serialization & deserialization of EJSON using bson package:

import { EJSON } from 'bson';

const data = { "_id": { "$oid": "613e8693499f15328a17e8b1" }, "name": "John", "age": 30 }

// serialization

const jsonString = EJSON.stringify(data, { relaxed: false });
// Output: '{"_id":{"$oid":"613e8693499f15328a17e8b1"},"name":"John","age":{"$numberInt":"30"}}'

// deserialization

const data = EJSON.stringify(data, { relaxed: false });
// Output: {
//  _id: new ObjectId("613e8693499f15328a17e8b1"),
//  name: 'John',
//  age: new Int32(30)
// }

Conclusion

In summary, Serialization is the process of converting data into a compact and structured format suitable for storage and transmission, while Deserialization is the process of converting the serialized data back into its original format.

Benchmarking String Literal ("") vs Template Literal (``) - using Performance.now()

Muhammad A Faishal — Thu, 27 Jul 2023 12:25:47 +0000

Let's talk about String in JavaScript. There are 2 ways developers can define a string:

a. Using String Literal

const str = "Hello " + "world!";

b. Using Template Literal

const worldText = "world!"
const str = `Hello ${worldText}`;

So, have you ever wondered what the difference between the tow? Which one do you usually use? Is the one you're using better?

Let's find out by doing performance test.

Benchmarking

Here are the test case and String Literal and Template Literal used for benchmarking.

Test Case

const iterations = ITERATION_TOTAL // 10, 100, 10000, 1000000
const stringText = 'string'
let text = ''

const start = performance.now()

for (let i = 0; i < iterations; i++) {
  // String or Template literal test case here
}

const end = performance.now()

console.log(`It took ${end - start} ms.`);

String Literal

text = "text"

Template Literal

text = `text`

String Literal concatenating a String

text = "text " + stringText

Template Literal concatenating a String

text = `text ${stringText}`

String Literal concatenating Two Strings

text = stringText + " text " + stringText

Template Literal concatenating Two Strings

text = `${stringText} text ${stringText}`

I ran the tests on Node Js v18.17.0 with different loop iterations: 10, 100, 10,000, 100,000, and 1,000,000. I measured the average times for each iteration.

Result

Here are the results for each iteration (the lower is better):

10 Iterations

100 Iterations

1,000 Iterations

100,000 Iterations

1,000,000 Iterations

Conclusion

It's still good to use both String Literal & Template Literal in simple iteration, displaying a limited items. The results showed a slightly different between the two which is still acceptable.

When dealing with processing large datasets, complex algorithm, generating long strings, using React components that frequently re-render that require a large number of iterations, String Literal is the only one to go.

It's important to understand that not every method is the best fit for every case and project. There might be some trade-offs to consider.

Benchmarking 'for', 'while', 'for...of', and 'Array.forEach' - using Performance.now()

Muhammad A Faishal — Wed, 19 Jul 2023 13:20:18 +0000

Currently, let's talk about looping in JavaScript! As we all know that there several methods to do it. Some of the methods that developers usually use are:

Developers love using Array.forEach because it's simple and easy to use. But, have you ever wondered why we have so many options for looping? Why not just get rid of the rest and stick with the best one?

Now, let's do some performance tests using Performance.now()!

Benchmarking

Here are the test cases and loops used for benchmarking.

Test Case

const iterations = ITERATION_TOTAL // 10, 100, 10000, 1000000, 10000000
const myArray = Array.from(Array(iterations).keys())

let total = 0

const start = performance.now()

// Looping method will be here

const end = performance.now()

console.log(`It took ${end - start} ms.`);

For

for (let i = 0; i < myArray.length; i++) {
  total += myArray[i]
}

While

let i = 0

while (i < myArray.length) {
  total += myArray[i]
  i++
}

For...of

for (const item of myArray) {
  total += item
}

Array.forEach

myArray.forEach((item) => {
  total += item
})

The tests were run with Node Js v18.17.0. Each loop was tested for different iterations: 10, 100, 10,000, 1,000,000, and 10,000,000. I averaged the times I got for each iteration.

Result

Here are the results for each loop with those iterations (the lower the better):

10 Iterations

100 Iterations

10,000 Iterations

1,000,000 Iterations

10,000,000 Iterations

Conclusion

For Frontend stuff, it's all good to use any of the loop methods (for, while, for...of, and Array.forEach) because most websites don't usually show more than 10,000 items on a page.

But when it comes to Backend Processing, Code Validation, Linting, etc., for and while loops are still totally the way to go! 🚀

So, not everything that's cool and easy on the developer side is the best for the project. There might be some trade-offs, you know. ✨

Unsafe 'PropsWithChildren' Utility type in React TypeScript App

Muhammad A Faishal — Sat, 15 Jul 2023 08:15:09 +0000

As React developer, we are all familiar with creating components, whether as classes or functions, to add features to web pages.

One of the common cases in React is a component that has JSX Children. When you want to nest content inside a JSX tag, the parent component will receive that content in a prop called children.

For instance, the Modal component below will receive children prop set to and render it in a wrapper div.

// React JavaScript

function Modal(props) {
  const { children } = props;

  return <div className="modal">{children}</div>;
}

function Page() {
  return (
    <Modal>
      <title>Submit Form</title>
      <form onSubmit={handleSubmit}>
        <input type="text" />
        <input type="submit" />
      </form>
    </Modal>
  );
}

If it wants to be converted to TypeScript, most of developers use PropsWithChildren utility type from @types/react package.

// React TypeScript

import type { PropsWithChildren } from "react";

// props: {
//    children?: React.ReactNode;
// }
function Modal(props: PropsWithChildren<{}>) {
  const { children } = props;

  return <div className="modal">{children}</div>;
}

function Page() {
  return (
    <Modal>
      <title>Submit Form</title>
      <form onSubmit={handleSubmit}>
        <input type="text" />
        <input type="submit" />
      </form>
    </Modal>
  );
}

It helps TypeScript understand that the component should have the children prop.

Problems

Sounds good so far, right? But here's where things get weird.

Let me highlight the code.

// props: {
//    children?: React.ReactNode; ❌
// }

// Unexpected ❌

import type { PropsWithChildren } from "react";

// props: {
//    children?: React.ReactNode;
// }
function Modal(props: PropsWithChildren<{}>) {
  const { children } = props;

  return <div className="card">{children}</div>;
}

function Page() {
  return <Modal />;
}

The children is supposed to be required. That means we must provide children when using Modal component. But, guess what? It becomes optional! Rendering Modal component without children is now even possible 😨.

Let's check what's inside PropsWithChildren. Here it is referring to @types/react Github.

type PropsWithChildren<P = unknown> = P & { children?: ReactNode | undefined };

Turns out the culprit is @types/react itself 😵.

This little bug might not seem like a big deal at first, but trust me, it can cause some serious problems and mess up with your business logic. And the worst part? Neither React nor TypeScript will show any errors, leaving you scratching your head when things go wrong 😵‍💫.

Solutions

So, what can we do about this? Let's explore some solutions!

1. Never Trust and Always Check "third-party" code

As you know earlier, the culprit is @types/react itself. This is not the first time. Previously, developers had a problem with React.FC. Some of them even posted about it.

TypeScript + React: Why I don't use React.FC
Why you probably shouldn’t use React.FC to type your React components
Why You Should Probably Think Twice About Using React.FC

All those fancy "magic" codes will eventually lose their "magic" over time. So, you should always check what's behind the code.

2. Create your own Utility type

Since the PropsWithChildren from @types/react is not that hard, why don't you create it yourself?

type PropsWithChildren<P = unknown> = P & { children: ReactNode };

PropsWithChildren utility type is for components that have children prop and it's required.

type PropsWithOptionalChildren<P = unknown> = P & { children?: ReactNode };

PropsWithOptionalChildren utility type is for components that have children prop, but it's optional.

It looks reliable and unambiguous. ✅

Conclusion

Remember these tips and you'll save yourself from headaches. I hope these tips come in handy for your projects! ✨

Avoid unsafe "&&" Operator for Conditional Rendering in React and Next.js

Muhammad A Faishal — Sat, 08 Jul 2023 14:04:44 +0000

Let's talk about something we all know when developing our project using React: Conditional Rendering.

When it comes to Conditional Rendering in React, there are multiple ways to implement it. One of the favorite ways among developers is using && operator.

const Text = (isDisplayed) => {
  return (
    <div>
      // this one
      {isDisplayed && <p>{text}</p>}
    </div>
  );
};

Basically, if the condition is true, a HTML <p> element with a specific text will be displayed. Otherwise, it won't be rendered at all.

But have you ever checked all the possible values that can be true and false? If not, let's check out the results below!

// Truthy values

// boolean
{true && <p>😸</p>}

// number
{20 && <p>😸</p>}

// string
{"string" && <p>😸</p>}

// object
{{} && <p>😸</p>}

// array
{[] && <p>😸</p>}

// function
{(() => {}) && <p>😸</p>}

// symbol
{Symbol("symbol") && <p>😸</p>}

// All of them will render <p>😸</p> ✅

So far, we haven't had to worry much about truthy conditions. But now, have you ever thought about what happens when the condition is falsy?

// Falsy values

// null - this won't render anything ✅
{null && <p>😸</p>}

// undefined - this won't render anything ✅
{undefined && <p>😸</p>}

// boolean - this won't render anything ✅
{false && <p>😸</p>}

// NaN - this will render NaN 🤯 ❌
{NaN && <p>😸</p>}

// 0 - this will render 0 🤯 ❌
{0 && <p>😸</p>}

// negative 0 - this will render 0 🤯 ❌
{-0 && <p>😸</p>}

// string - this won't render anything ✅
{"" && <p>😸</p>}

As it turns out, not all falsy values give the expected result. It can be quite baffling! 🤯 This issue often arises when dealing with a Notification Badge.

You might think it's a minor problem, but guess what? Many developers simply forget to deal with it the right way!

Solutions

Luckily, I've got a handful of solutions for this issue.

1. Convert `condition` to Boolean

// NaN
{Boolean(NaN) && <p>😸</p>}

// 0
{Boolean(0) && <p>😸</p>}

// negative 0
{!!-0 && <p>😸</p>}

// string
{!!"" && <p>😸</p>}

// All of them won't render anything ✅

You can handle this by using the Boolean(expression) function or the double NOT operator !!expression. These methods will convert any data type into a boolean value. As seen in the results above, both true and false work perfectly fine in this case.

2. Use Ternary operator

// NaN
{NaN ? <p>😸</p> : null}

// 0
{0 ? <p>😸</p> : null}

// negative 0
{-0 ? <p>😸</p> : null}

// string
{"" ? <p>😸</p> : null}

// All of them won't render anything ✅

When the condition is falsy, you can use the ternary operator to return null instead.

Conclusion

So, we'll save ourselves from headaches and level up the quality of our code if we keep these things in mind. I hope this post has provided useful insights for your projects! ✨

Bonus

If you already have eslint-plugin-react installed, you can enable the following rule.

{
  // ...
  "react/jsx-no-leaked-render": ["error", { "validStrategies": ["coerce"] }]
  // ...
}

By doing so, ESLint will automatically replace all your Conditional Rendering codes to boolean.

// From this ❌
{NaN && <p>😸</p>}

// To this ✅
{!!NaN && <p>😸</p>}

Safely use `JSON.parse()` in TypeScript

Muhammad A Faishal — Wed, 05 Jul 2023 15:00:00 +0000

Let's talk about something that most of us can relate to: JSON.parse(). We all know that thing we use to turn a JSON string into an object.

const jsonString = '{ "title": "Title" }'

const jsonValue = JSON.parse(jsonString)
// { title: 'Title' } ✅

Problems

Now, here's the thing...

Have you ever wondered what happens when you mess around with the value of jsonString? Let's say you change '{ "title": "Title" }' to ''. Well, guess what? The expected turns into... ERROR! 🤯

const jsonString = ''

const jsonValue = JSON.parse(jsonString)
// Error: Unexpected end of JSON input ❌ 💣

It may seems like a small issue, but guess what? Lots of developers forget to handle it properly!

Now, here's the interesting part...

In TypeScript, JSON.parse() doesn't have any specific type arguments. It just returns any. This means, it comes at the cost of losing the benefits of static typing and type safety.

const jsonString = "";

const jsonValue = JSON.parse(jsonString)
// const jsonValue: any ❌

When developers treat potentially unsafe data as completely safe, it can cause some really frustrating errors to deal with. 😫

Solutions

But don't worry, I've got a couple of solutions! 💡

1. Create "safeJsonParse" function

const safeJsonParse = <T>(str: string) => {
  try {
    const jsonValue: T = JSON.parse(str);

    return jsonValue;
  } catch {
    return undefined;
  }
};
// const safeJsonParse: <T>(str: string) => T | undefined ✅

This function is responsible for handling parsing errors. If an error occurs during parsing, it will return undefined. Otherwise, it will return the parsed JSON value along with its corresponding data type.

2. Add fallback

interface JsonValue {
  title: string
}

const jsonString = '{ "title": "Title" }'

const jsonValue = safeJsonParse<JsonValue>(jsonString) || { "title": "" }
// const jsonValue: JsonValue ✅

Just in case the value is undefined, we can add a fallback mechanism. This ensures that the value will always be provided, regardless of what happens.

Conclusion

So, if we keep these things in mind, we'll avoid headaches and make our code super solid. I hope you find these tips useful for your projects! You got this! ✨

Avoid using "array[index]" for getting Array elements

Muhammad A Faishal — Tue, 04 Jul 2023 14:26:47 +0000

Hey there, fellow developers! 👋

Let's talk about something that might ring a bell for many of us: accessing elements in an array. We all know that familiar way of grabbing array elements using Property Accessors like array[index]. It's pretty straightforward, right?

const arr = [7]

const firstElement = arr[0]
// 7 ✅

Problems

Well, here's the catch. Have you ever wondered what happens when you tweak the index? Let's say you change arr[0] to arr[1]. In that case, the value you'd expect from arr[1] suddenly becomes... undefined! 🤯

const arr = [7]

const firstElement = arr[1]
// undefined ❌

Yep, the second element you were counting on just vanishes into thin air. It might sound like a minor hiccup, but guess what? Many developers forget to guard against it!

Now, here's where it gets interesting...

TypeScript, which is a tool that helps catch sneaky bugs, somehow fails to detect this issue. TypeScript still thinks the type of arr[1] is a solid number, despite it being undefined.

First case:

Second case:

And you know what's even riskier? When TypeScript considers potentially unsafe data as perfectly safe values, it can trigger nasty errors that are a real headache to debug. 😫

Solutions

But hey, fear not! I've got a couple of solutions that can save the day:

1. Use `Array.at()`

First case:

Second case:

It's an alternative method to access array elements, apart from the traditional property accessors. By replacing arr[0] with arr.at(0), TypeScript will smartly infer the type as number | undefined.

This method knows how to handle those pesky undefined elements, making your code safer. If you're curious, you can find a polyfill (a code snippet that adds support for new features) for it on GitHub: link to polyfill.

2. Always add fallback

TypeScript will strongly encourage you to add a fallback value whenever you encounter a potentially undefined element. You can go for value = arr.at(0) || fallback.

This way your fallback value will save the day.

Conclusion

By keeping these considerations in mind and implementing these nifty solutions, you'll be dodging bullets and making your code rock-solid. 🛡️ So, let's make sure those pesky undefined array elements don't catch us off guard! Hope you find these tips useful for your projects! ✨

DEV Community: Muhammad A Faishal

JavaScript `string.replace()` useful cases

1. Simple String Replacement

2. Global String Replacement

3. Case-insensitive Replacement

4. Replace Whole Words (Word Boundary)

5. Using a Function for Replacement

6. Capturing Groups with Replacement

7. Escaping Special Characters

8. Replacing Non-ASCII Characters

9. Replacing Digits

10. Replacing Special Characters using Unicode

11. Replace Words using Lookbehind and Lookahead assertion

Use "@ts-expect-error" over "@ts-ignore" in TypeScript

Conclusion

Bonus

Better Git Commits with `@commitlint`

You might not need TypeScript Enum

Data Types

Enum

Constants

Transpiled Size

Enum

Constants

How to use

Enum

Constant

Conclusion

JavaScript CONSTANTS

Naming Convention

Examples

Other uses

Serialization and Deserialization in JavaScript

Serialization

Deserialization

Other Formats

BSON

EJSON

Conclusion

Benchmarking String Literal ("") vs Template Literal (``) - using Performance.now()

Benchmarking

Result

Conclusion

Benchmarking 'for', 'while', 'for...of', and 'Array.forEach' - using Performance.now()

Benchmarking

Result

Conclusion

Unsafe 'PropsWithChildren' Utility type in React TypeScript App

Problems

Solutions

1. Never Trust and Always Check "third-party" code

2. Create your own Utility type

Conclusion

Avoid unsafe "&&" Operator for Conditional Rendering in React and Next.js

Solutions

1. Convert condition to Boolean

2. Use Ternary operator

Conclusion

Bonus

Safely use `JSON.parse()` in TypeScript

Problems

Solutions

1. Create "safeJsonParse" function

2. Add fallback

Conclusion

Avoid using "array[index]" for getting Array elements

Problems

Solutions

1. Use Array.at()

2. Always add fallback

Conclusion

1. Convert `condition` to Boolean

1. Use `Array.at()`