Forem: phukon

Babel and Sourcemaps, Part-1

phukon — Sun, 13 Oct 2024 13:37:32 +0000

Repurposing source-maps with a Babel codemod.

I began working with sourcemaps a while ago and was fascinated by their ingenuity. This sparked an idea: what if sourcemaps could be used for other purposes? Specifically, I thought of applying them to documentation — comments, README files, and so on.

That’s how ‘DOCMAP’ was born! The process works by adding comments in the source code with a specific prefix. Then, Babel is run on the source code, stripping out the comments from the original files without modifying the JavaScript/TypeScript/JSX/TSX code itself. These comments are compiled into a single README file, and a sourcemap is generated for the comments!

This will keep all the juicy comments right where they belong, pinpointing them to the relevant code without cluttering up the original source

A Primer

Babel

JavaScript is an evolving language, with new features and syntax being introduced regularly. However, not all browsers and environments immediately support the latest JavaScript features. This can create compatibility issues for developers who want to use modern language features while ensuring their code runs smoothly across all platforms. This is where transpiling comes in.

Transpilers help bridge this gap by converting modern JavaScript code into older versions that are widely supported across different browsers. One popular transpiler is Babel, which not only allows developers to transpile code but also to create and run code mods—automated transformations of code.

Sourcemaps

Now that we understand what Babel is and what it can do, let's address a common issue.

When debugging compiled code in the browser’s debugger, problems can arise. The code running in the browser isn’t the code you originally wrote, making it difficult to follow and debug.

Source maps offer a solution to this. They map the compiled code back to your original source code, allowing the debugger to display the code you wrote while still running the compiled version behind the scenes.

But what does a sourcemap look like?

If we compile this ES 2015 code with Babel:

const square = (x) => x * x;

It is transformed into this:

"use strict";

var square = function square(x) {
  return x * x;
};

//# sourceMappingURL=test.js.map

And this is the source map content inside “test.js.map”:

{
    "version": 3,
    "sources": ["test.es6.js"],
    "names": [],
    "mappings": ";;AAAA,IAAM,MAAM,GAAG,SAAT,MAAM,CAAI,CAAC;SAAK,CAAC,GAAG,CAAC;CAAA,CAAC",
    "file": "test.js",
    "sourcesContent": ["const square = (x) => x * x;"]
}

What are those weird alphabets in the mappings key?
These are called Base 64 VLQ. VLQ stands for variable-length quantity, and it’s used to store a number in a more space-efficient way than storing its digits as a string.

The individual mapping entries, such as "AAAA" and "GAAG," are known as "segments." Each segment represents an array of numbers.

In the sourcemap world. Everything is zero indexed (lines and columns)
A semicolon (;) means skip to next line in the output file.

[0]: Column index in the compiled file
[1]: What original source file the location in the compiled source maps to
[2]: Row index in the original source file (i.e. the number of lines to move from the current position)
[3]: Column index in the original source file

Source maps do not represent the position of every character; instead, they use relative values to indicate the proximity of source code locations.

For example, if a column value is decoded to 8 and the next segment's column value is 10, the mapping indicates a change of +10 (rather than an absolute position of 10). We have to move 10 lines from the previous segment's decoded position in the original code. Therefore, each segment's current VLQ value depends on and is derived from its predecessors.

This relative approach is especially useful when working with large codebases, as it keeps the source map concise while still enabling accurate debugging.

The code mod

How does the codemod script work?

Parse Code to AST:
- The source code is tokenized and analyzed to create an Abstract Syntax Tree (AST), a structured representation of the code.
Transform AST to Another AST:
- The AST is optimized or transformed through semantic analysis (e.g., type checking, optimizations like dead code elimination) to improve efficiency. But in our case, we are removing comment nodes from the code.
Generate Code from AST:
- The optimized AST is translated into the target code (e.g., machine code or bytecode) that can be executed. In our case, we are translate the AST without the comment nodes into code.

In short: Parse → Transform → Generate.

When working with Babel, you generally add nodes to paths rather than directly to nodes. What’s a node and a path in the Babel AST you might ask?

Nodes: These represent the actual elements of the Abstract Syntax Tree (AST). For example, a variable declaration, function call, or any other part of the code is a node. However, nodes are just data structures; they don’t know their position or context within the AST.
Paths: A NodePath is a wrapper around a node that includes information about its position in the AST and the scope it belongs to. Paths provide methods for navigating and manipulating the AST, such as insertBefore, insertAfter, replaceWith, and more.

Note

We use the visitor pattern while using babel for transformations. A visitor matches a node in the AST and returns a path! This path wraps the node (ex: CallExpression) and provides methods to interact with it.

What the Path Object Provides:

Node Access: You can access the actual AST node via path.node.
Parent Node: Access the parent node via path.parent.
Sibling Nodes: Navigate to sibling nodes via methods like path.getSibling(index).
Node Replacement: Replace the current node with path.replaceWith(newNode).
Traversal: Traverse into child nodes using path.traverse() with another visitor.
Contextual Information: The path includes context about the scope, which can be important for variable declarations, function parameters, etc.

So, that wraps up Part 1! We’ve explored how Babel lets us use modern JavaScript features while making sure our code runs smoothly across different browsers. We also talked about sourcemaps and how they help us debug by linking the compiled code back to the original source, which is super handy.

Plus, we introduced the idea of DOCMAP, a cool way to repurpose sourcemaps for documentation. It keeps those juicy comments tied to the right code without cluttering things up.

In Part 2, we’ll dive into how DOCMAP works, showing you the steps for extracting comments and generating a neat README. Can’t wait to get into it!

Resources

About sourcemaps: https://pvdz.ee/weblog/281
Base64 VLQ decoder: http://www.murzwin.com/base64vlq.html
Good read: https://www.linkedin.com/pulse/reconstructing-javascript-source-code-from-maps-schaffner-bofill/
Generating source maps: https://www.mattzeunert.com/2016/02/14/how-do-source-maps-work.html
VLQ npm package documentation: https://www.npmjs.com/package/vlq
Sentry’s Video on sourcemaps: https://www.youtube.com/watch?v=6LI0BJIiamg
AST Explorer: https://astexplorer.net

Be a Better UI Engineer: Selectively Exclude CSS Styles

phukon — Sun, 21 Apr 2024 06:06:50 +0000

Fine grained control over your styles in 3 steps

Correcting the styles. Before and after.

The Problem

I wanted to increase the sizes of the images in my personal site’s projects page. So I wrote some styles in globals.css, and applied it to the parent node that contains the content.

This style applies to all images within elements with the classes .prose and .project.

.prose.project img {
 @apply max-w-none rounded-md border border-secondary bg-tertiary md:rounded-lg lg:-ml-16 lg:w-[calc(100%+128px)];
}

The problem arises with this dynamic classlg:w-[calc(100%+128px)]. It adds 128 pixels to 100% of the parent element’s width. This is a common technique in CSS for achieving responsive and dynamic layouts.

This made the images in one of my custom MDX components to blow out of proportions.

See the red NPM logo image that’s out of proportion.

I don’t want this global style to be applied. How do I go about excluding it?

The Solution

The key to solving this problem lies in understanding how CSS selectors work and how to leverage them to target specific elements. In our case, we want to exclude the global style from one specific element.

Step 1: Add a Custom Class to the component

First, add a custom class to the element/component where you don’t want the global style to be applied. For example, you can add a class named .no-prose-style.

<div
 className="project prose animate-in no-prose-style"
 style={{ "--index": 2 } as React.CSSProperties}
>

Step 2: Define the Override Styles in CSS

Next, define the styles you want to override or reset for the .no-prose-style class in your CSS. You can reset the properties to their default values or set them to something else as needed.

In my case, the problem revolved around images blowing out of proportions in my custom component. Hence, I set the width on large screens to be 100% with a Tailwind utility class.

The the class to override the prose project style

.no-prose-style img {
  @apply lg:w-full;
 }

The result:

The red NPM logo looks great now!

In conclusion, by understanding CSS selectors and utilizing targeted overrides, we can maintain fine-grained control over our styles in Tailwind CSS. With just a few simple steps, we can exclude global styles from specific elements, ensuring a more tailored and cohesive design across our projects.

Footnotes:
GitHub: https://github.com/phukon
Socials: https://rkph.me

How I test React components in isolation

phukon — Sun, 14 Apr 2024 15:08:12 +0000

Are you even a frontend engineer if you don’t develop/test your components in isolation?

In modern frontend development, testing components in isolation is crucial for ensuring code quality and efficiency. Storybook is a powerful tool that facilitates this practice, allowing developers to develop and showcase UI components independently.

Testing components in Storybook. For more @see [BinaryDreams](https://bndr.rkph.me)

Step 1

We need to initialize it in our project. Go to the root directory and do:
npx storybook@latest init

Good! If you’re utilizing ESLint in your project, you’ll receive a prompt asking if you’d like to install the necessary dependencies that align with Storybook. Simply respond with “y” and proceed.

Excellent! Upon inspection of your project, you’ll notice that Storybook has generated a .storybook folder and a stories folder.

The .storybookdirectory houses configuration files, while the stories folder contains example Stories.

Chances are, installing Storybook in your project also started the Storybook development server at http://localhost:6006/, if not, try npm run storybook in your project using the terminal.

What do we see?

We see a beautiful✨ dashboard with all the Stories defined in your project! (these are examples stories that come with the installation)

Click on a Story and you get a good overview of the component along with it’s description, the props it takes, etc.

Congrats! You’ve just setup Storybook for your project. BUT you need to jazz it up by properly plugging in TailwindCSS. (cuz who doesn’t TailwindCSS?)

Setup Absolute Imports

Storybook doesn’t support absolute imports out of the box. For this we have to do a minor change in the config. Open .storybook/main.ts and add this snippet in the config object.

webpackFinal: async (config) => {
    if (config.resolve) {
      config.resolve.alias = {
        ...config.resolve.alias,
        "@": path.resolve(__dirname, "../"),
      };
    }
    return config;
  }

Setup Tailwind!

Unless you’ve been living in a cave (or under a rock, if you prefer), you probably know how crucial TailwindCSS is in the modern web dev scene. But the TailwindCSS utility classes won’t work with Storybook out of the box.

So here’s what you have to do

open the file preview.ts in the .storybook folder
import your main CSS file, or in my case globals.css

Import globals.css

You’re doing great!

Stories are a declarative syntax for supplying props and mock data to simulate component variations. Each component can have multiple stories. Each story allows you to demonstrate a specific variation of that component to verify appearance and behavior.
You write stories for granular UI component variation and then use those stories in development, testing, and documentation.

This is very simple, don’t worry if you can’t get a hold of it in the beginning. We write a story by importing a component we made in to a file ending with .stories

If you are making a Story for LoginForm.tsx, make a file called LoginForm.stories.tsx.

A Story

We’ve imported some types from Storybook since we’re using Typescript in this project.
We then import the component that we want test/develop in isolation and define write meta data for the component.
Add the name of our component with the category under which it should be grouped. Here, the title is “Auth/LoginForm”. ‘Auth’ is the category. Think of it as a directory structure.

We have currently defined to categories. Auth and Onboard

Don’t worry about this part. You can just copy this meta object in every component. But do change the name and define the imported component for which you’re setting the Story for!
These lines imports types Meta and StoryObj from the @storybook/react package.

satisfies Meta<typeof LoginForm>;

export default meta;
type Story = StoryObj<typeof meta>;

These types are used to define the structure of stories and their metadata within Storybook.

import type { Meta, StoryObj } from "@storybook/react";
import LoginForm from "./LoginForm";

const meta = {
  title: "\"Auth/LoginForm\", // category/unique_name"
  component: LoginForm, // the imported component

  tags: ["autodocs"],
  parameters: {
    layout: "fullscreen",
  },
} satisfies Meta<typeof LoginForm>;

export default meta;
type Story = StoryObj<typeof meta>;

export const LoginFormLight: Story = {};

We define stories according to the Component Story Format (CSF), an ES6 module-based standard that is easy to write and portable between tools.

The key ingredients are the default export that describes the component, and named exports that describe the stories.

Voila! You now know how to use StoryBook!

Do note that I’ve not touched upon powerful features like decorators, adding contexts to stories etc. That’s for another day.

Keep building, keep learning. After all, there’s nothing that teaches like a project!

Footnotes:

Checkout my repo to see how I’ve used Storybook : BinaryDreams

How I write Commits like a pro

phukon — Mon, 08 Apr 2024 12:40:11 +0000

Crafting effective commit messages is a hallmark of experienced developers. Embracing the Conventional Commits specification stands as a beacon for structuring commit messages. It’s not just a guideline; it’s a pathway to a clearer commit history that harmonizes with Semantic Versioning (SemVer).

What are Conventional Commits?

Conventional Commits offer a lightweight yet powerful framework for organizing commit messages. By categorizing changes into distinct types like features, fixes, and breaking changes, it sets a gold standard for clarity and consistency and aligns with Semantic Versioning (SemVer) by categorizing changes into features, fixes, and breaking changes.

The Anatomy of a Great Commit Message

When making commits, please use the conventional commit format, which typically follows the pattern of <type>: <description>.

A commit message should follow this structure:



<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

type: type of commit

scope: Short description of a section of the codebase enclosed in parenthesis followed by a colon and a space. Messages tend to be in the present and imperative.

description: Short description of the code changes

body: A longer description of the commit, providing additional context about the changes.
Must be placed one empty line after the description.

footer: Fixes issue #3 //example
The footer should only contain additional issue references about the changes.

Examples:

A commit I made to solve an issue.



feat(homepage): Add carousel feature to showcase testimonials

Implemented a carousel component on the homepage
Added client testimonials section for improved user engagement

Fixes #12

More examples:

feat: Add new rating component
fix: Resolve issue with city search feature
docs: Update README with new contribution guidelines

Types of Commits

In addition to the classic fixand feat, we've got a whole buffet of commit types. It's like choosing toppings for your commit pizza:

build: Changes related to build processes or tools.
chore: Regular maintenance or administrative tasks.
ci: Updates to the continuous integration setup.
docs: Documentation-related changes.
style: Changes that do not affect the code’s functionality (e.g., formatting).
refactor: Code modifications without changing its behavior.
perf: Performance improvements.
test: Adding or modifying tests.

You can use these types to categorize your commits according to their nature. This helps maintain consistency in commit messages and aids in better organization of changes in the project history.

Footnote

For more information on Conventional Commits, visit Conventional Commits Specification.

How I Structure my React Projects

phukon — Sat, 06 Apr 2024 16:36:43 +0000

Ever dreamt of a React app that chuckles at bugs and scoffs at spaghetti code? Let’s embark on a journey to create a React app so robust it could survive an apocalypse of bad coding practices.

In those novice days, my code resembled a wild creature — functional, yet utterly chaotic. The project structure, if you could call it that, was a disorganized mess. It sufficed for my humble beginnings, but as the project grew, so did the complexity, and chaos ensued.

Inexperienced dev ⤵

Experienced dev ⤵

With each expansion of the project, finding a specific piece of code became a quest akin to searching for a needle in a haystack, only to realize that the needle was a variable aptly named ‘needle’ buried somewhere deep in the code.

Take the time to learn how to structure your React project before your codebase transforms into an unsolvable mystery novel.

How a project should look like:

src
|
+-- assets            
|
+-- components        
|
+-- config           
|
+-- features          
|
+-- hooks             
|
+-- lib               
|
+-- providers         
|
+-- routes            
|
+-- stores            
|
+-- test              
|
+-- types             
|
+-- utils

components: Shared components that grace the entire kingdom
config: The vault of global configurations, env variables, and secrets
features: Feature based modules
hooks: Mystical hooks, shared across the entire realm
libs: re-exporting different libraries preconfigured for the application
providers: Keepers of the application’s life force, the providers
routes: routes configuration
stores: global state stores
test: The arena of trials, where utilities and mock servers prove their mettle
types: base types used across the application
utils: shared utility functions

Now, let’s descend into the heart of a feature.

src/features/my-new-feature
|
+-- api         # Declarations and API hooks, a symphony of requests for this feature
|
+-- assets      # Treasures specific to the awesome feature
|
+-- components  # Components, artisans sculpting the visual identity of the feature
|
+-- hooks       # Hooks, magical spells woven into the fabric of this feature
|
+-- routes      # Paths leading to the feature's pages, a roadmap of wonder
|
+-- stores      # Keepers of state, guarding the feature's sacred truths
|
+-- types       # TypeScript types, a lexicon for the feature's domain
|
+-- utils       # The craftsmen, building utility functions exclusive to this feature
|
+-- index.ts    # The grand entrance, the public API of this feature, revealing its essence

The index file

Everything from a feature should be exported from the index.ts file which behaves as the public API of the feature.

Notice the index file for each component folder. ⤴

You should import stuff from other features only by using:

import {AwesomeComponent} from "@/features/awesome-feature"

and not

import {AwesomeComponent} from "@/features/awesome-feature/components/AwesomeComponent

Set up absolute imports!

Absolute imports can make your import statements cleaner and more readable. They also help in avoiding long relative import paths.

//  jsconfig.json/tsconfig.json
"compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  }

Remember, every developer, seasoned or fledgling, has danced the maddening tango with spaghetti code. But with structure comes clarity, and with clarity comes the power to wield React with finesse.

So, as you forge your own path in the realms of frontend development, let this blueprint be your guiding light, your treasure map to organized brilliance. May your React projects chuckle at bugs, scoff at chaos, and stand firm in the face of coding calamities.

Personal links.:
web
GitHub

Footnotes:
https://github.com/alan2207/bulletproof-react

WTF is a Monad?!

phukon — Mon, 01 Apr 2024 10:12:54 +0000

A monad in X is a monoid in the category of endofunctors of X.

I came across the term MONAD in a meme and when I googled. The above sentence was what I got.
Not very helpful when you’re trying to learn about monads in functional programming isn’t it?

All monads have three components:

Wrapper Type: A wrapper of some sorts that mark the type of the component.
Wrap Function (allows entry to monad ecosystem): A function that takes normal values and wraps it up in a monad, like a constructor of sorts. These are called return, pure or unit
Run Function (runs transformations on monadic values): Takes the wrapper type and transform function(not the Wrap Function) that accepts the unwrapped type and returns the wrapper type. Runs the transformation function on the argument passed in. aka bind, flatmap, '>>='' (this symbol)

Let’s start with some code

/**
 * @see [GitHub](https://github.com/phukon/practice/tree/main/monadic-stuff)
 */

function square(x: number): number {
  return x * x;
}

function addOne(x: number): number {
  return x + 1;
}

console.log(addOne(square(2)));
The above code demonstrates basic arithmetic operations without using monads. We have simple functions for squaring a number and adding one to a number.

Let’s spice it up a bit

We undertake a substantial refactoring of the previous code, introducing a structured format that amalgamates the numerical output with an array of logs.

/**
 * @see [GitHub](https://github.com/phukon/practice/tree/main/monadic-stuff)
 */

interface NumberWIthLog {
  result: number;
  logs: string[];
}

function square(x: number): NumberWIthLog {
  return {
    result: x * x,
    logs: [`Squared ${x} to get ${x * x}`],
  };
}

function addOne(x: NumberWIthLog): NumberWIthLog {
  return {
    result: x.result + 1,
    logs: x.logs.concat([
      `Added 1 to ${x.result} to get the result ${x.result + 1}`,
    ]),
  };
}

console.log(addOne(square(3)));

This restructuring serves as a preparatory step towards implementing a monadic pattern, aimed at proficiently managing computations while concurrently logging operations. Key components within this file include:

NumberWithLog Interface: This encapsulates both the result and log array, enhancing the code’s structural integrity.

Functions:

square: Computes the square of a number and meticulously logs the operation.
addOne: Increments a given NumberWithLog input by one, effectively documenting this process within the logs. The provided console log shows the usage of the addOne function on the square of 3.

But there’s a catch

When working with nested operations like square(square(2)) or addOne(5), we will encounter type mismatches and limitations within our code. To address these issue, we'll delve into implementing a more robust solution using monadic patterns.

The ‘NumberWithLog’ Interface

Firstly, we define an interface called NumberWithLog to contain both the numerical result and logs, crucial for our computations.

interface NumberWithLog {
  result: number;
  logs: string[];
}

Creating a Wrapper Function

We introduce a constructive function, wrapWithLogs, serving as a wrapper around a numerical value. It initializes a NumberWithLog object with the input number and an empty log array, priming it for subsequent operations.

/**
 * Constructs a 'NumberWithLog' object by wrapping a numerical value.
 * @param x The number to be wrapped within 'NumberWithLog'.
 * @returns A 'NumberWithLog' object initialized with the input number and an empty log array.
 */
function wrapWithLogs(x: number): NumberWithLog {
  return {
    result: x,
    logs: [],
  };
}

Enhanced Functions for Operations

We enhance the square and addOne functions to operate on NumberWithLog objects. square computes the square of a NumberWithLog and meticulously records the operation in the logs. Similarly, addOne increments the result within a NumberWithLog object by one while logging the process.

square function

// Tweaked versions of square and addOne functions to operate on NumberWithLog

/**
 * Computes the square of a 'NumberWithLog' and records the operation in logs.
 * @param x The 'NumberWithLog' object whose result will be squared.
 * @returns A 'NumberWithLog' object with the squared result and updated logs.
 */
function square(x: NumberWithLog): NumberWithLog {
  return {
    result: x.result * x.result,
    logs: [`Squared ${x.result} to get ${x.result * x.result}`],
  };
}

addOne function

/**
 * Adds one to the 'NumberWithLog' result and logs the operation.
 * @param x The 'NumberWithLog' object to which one will be added.
 * @returns A 'NumberWithLog' object with the incremented result and updated logs.
 */
function addOne(x: NumberWithLog): NumberWithLog {
  return {
    result: x.result + 1,
    logs: x.logs.concat([
      `Added 1 to ${x.result} to get the result ${x.result + 1}`,
    ]),
  };
}

Utilizing the Functions

To showcase the functionality, we display the result of square(square(wrapWithLogs(2))) in the console. This demonstrates the nested application of these functions and the effective handling of computations and logging within our codebase.

By leveraging these techniques, we resolve the type mismatch issues.

/**
 * Issues:
 * As evident, the previous implementation faces limitations with nested operations like square(square(2)) or addOne(5),
 * resulting in type mismatches. We aim to resolve this issue with a new function that acts as a constructor-like wrapper.
 * This wrapper function encapsulates the input within the 'NumberWithLog' structure to facilitate nested operations.
 * 
 * @see [GitHub](https://github.com/phukon/practice/tree/main/monadic-stuff) 
*/

// Interface to hold both the result and logs
interface NumberWithLog {
  result: number;
  logs: string[];
}

/**
 * Constructs a 'NumberWithLog' object by wrapping a numerical value.
 * @param x The number to be wrapped within 'NumberWithLog'.
 * @returns A 'NumberWithLog' object initialized with the input number and an empty log array.
 */
function wrapWithLogs(x: number): NumberWithLog {
  return {
    result: x,
    logs: [],
  };
}

// Tweaked versions of square and addOne functions to operate on NumberWithLog

/**
 * Computes the square of a 'NumberWithLog' and records the operation in logs.
 * @param x The 'NumberWithLog' object whose result will be squared.
 * @returns A 'NumberWithLog' object with the squared result and updated logs.
 */
function square(x: NumberWithLog): NumberWithLog {
  return {
    result: x.result * x.result,
    logs: [`Squared ${x.result} to get ${x.result * x.result}`],
  };
}

/**
 * Adds one to the 'NumberWithLog' result and logs the operation.
 * @param x The 'NumberWithLog' object to which one will be added.
 * @returns A 'NumberWithLog' object with the incremented result and updated logs.
 */
function addOne(x: NumberWithLog): NumberWithLog {
  return {
    result: x.result + 1,
    logs: x.logs.concat([
      `Added 1 to ${x.result} to get the result ${x.result + 1}`,
    ]),
  };
}

// Displaying the result of square(square(wrapWithLogs(2)))
console.log(addOne(square(wrapWithLogs(2))));

The Monad

We starts by addressing a challenge faced in prior implementations when dealing with nested operations like square(square(2)) or addOne(5). Attempting to modify square and addOne to accommodate ‘NumberWithLog’ inputs led to rendering these original functions obsolete.

The Monadic Revelation:

Enter ‘runWithLogs’, a game-changer in the landscape of this challenge. This higher-order function revolutionizes the approach without altering existing functions.

/**
 * Executes a transformation on a 'NumberWithLog' object using the provided function
 * and logs the operations performed.
 * @param input The 'NumberWithLog' object to transform.
 * @param transform The transformation function to apply to the 'NumberWithLog' object.
 * @returns A 'NumberWithLog' object after applying the transformation and logging the operations.
 */
function runWithLogs(
  input: NumberWithLog,
  transform: (x: number) => NumberWithLog
): NumberWithLog {
  const newNumberWithLog = transform(input.result);
  return {
    result: newNumberWithLog.result,
    logs: input.logs.concat(newNumberWithLog.logs),
  };
}

It gracefully accepts NumberWithLog objects and transformation functions, enabling seamless chaining of operations while retaining meticulous logs. This paradigm shift aligns with the monadic pattern, offering enhanced flexibility, maintainability, and a definitive resolution to type mismatch issues.

// Example usage of 'runWithLogs' function to chain operations on 'NumberWithLog' object
const a = wrapWithLogs(2);
const b = runWithLogs(a, addOne);
const c = runWithLogs(b, square);
console.log(c);

A simple console log demonstrates the prowess of ‘runWithLogs’, showcasing its ability to seamlessly chain ‘addOne’ and ‘square’ operations on a ‘NumberWithLog’ object initialized with a value of 2.

Mapping the components to the code in this tutorial

Remember I said that all monads have three components? This is how our code maps to the components :-

Wrapper Type: NumberWithLog
Wrap Function: function wrapWithLogs
Run Function: function runWithLogs

Animation

If you look closely, Monads allow a user to chain operations while the Monad manages the secret work behind the scenes.

Footnotes:

A monad is a monoid in the category of endofunctors. Whats the problem?
What is a Monad? — Computerphile
The Absolute Best Intro to Monads For Software Engineers