DEV Community: SebasQuiroga

🕒✨ Mastering Time Overlaps in TypeScript: 🚀 Tackling Cross-Midnight Challenges 🌙

SebasQuiroga — Fri, 21 Mar 2025 22:59:39 +0000

📌 TL;DR: In this post, we explore how to accurately detect time overlaps in Typescript, including cross-midnight cases. You’ll learn how to handle tricky edge cases and implement a robust solution using React, TypeScript, and functional programming techniques.

🔗 GitHub Repo: GitHub Link
🎬 Live Demo: Demo Link

🚀 The Problem: Detecting Time Overlaps

Time overlap detection is a common problem in scheduling applications. Suppose you have:

An availability window (e.g., 22:00 - 06:00)
A new event/test window (e.g., 23:30 - 02:00)

How do you check if they overlap, considering that both cross midnight?

Most naive implementations fail when dealing with time ranges that span across two days. In this post, we’ll build a robust solution to handle all possible cases!

🧐 Understanding the Edge Cases

Before jumping into code, let’s break down the possible scenarios:

🔥 Let’s jump into it 🏊🏼

A time window can be represented as an interval [start, end] where start and end are the minutes since midnight

(e.g., 22:00 → 1320 mins, 06:00 → 360 mins). If end < start, it crosses midnight (e.g., 22:00 - 06:00 → [1320, 360])

The key idea is:

✅ Two intervals overlap if and only if:

segment1.start < segment2.end && segment2.start < segment1.end

🏗️ Implementing solution

Let’s break the solution into logical steps:

1️⃣ Convert Time Strings (HH:mm) to Minutes

Converting a 24-hour circular timeline into a linear sequence of minutes greatly simplifies the logic.

const Time24FormatToMinutes = (time: string): number => {
  const [hours, minutes] = time.split(":").map(Number);
  return hours * 60 + minutes;
};

2️⃣ Define the Overlap Check Logic

const checkSegmentOverlap = (
  segment1: { start: number; end: number },
  segment2: { start: number; end: number }
): boolean => segment1.start < segment2.end && segment2.start < segment1.end;

3️⃣ Handle Midnight Cases

Creating a seamless timeline of minutes is achieved by adding 24 hours (1440 minutes) to time intervals that extend past midnight.

const handleMidnightCrossing = (start: number, end: number) => ({
  firstDay: { start, end: end === 0 ? 1440 : end },
  secondDay: end === 0 ? { start: 0, end } : null
});

4️⃣ Wrapping the logic in a React Hook

useEffect(() => {
    if (
      !availableStartTime ||
      !availableEndTime ||
      !testStartTime ||
      !testEndTime
    ) {
      setOverlaps(true);
      return;
    }

    const checkSegmentOverlap = (
      segment1: { start: number; end: number },
      segment2: { start: number; end: number }
    ) => {
      return segment1.start < segment2.end && segment2.start < segment1.end;
    };

    const availableStart = Time24FormatToMinutes(availableStartTime);
    const availableEnd = Time24FormatToMinutes(availableEndTime);
    const testStart = Time24FormatToMinutes(testStartTime);
    const testEnd = Time24FormatToMinutes(testEndTime);

    // Handle special case of midnight (0 minutes)
    // If end time is midnight (0), treat it as end of day (1440 minutes)
    const adjAvailEnd = availableEnd === 0 ? 1440 : availableEnd;
    const adjTestEnd = testEnd === 0 ? 1440 : testEnd;

    // Check if each range crosses midnight
    const availCrossesMidnight = availableStart >= adjAvailEnd;
    const testCrossesMidnight = testStart >= adjTestEnd;

    // For each range, create two "day segments" that represent
    // the parts of the range before and after midnight
    const availFirstDay = {
      start: availableStart,
      end: availCrossesMidnight ? 1440 : adjAvailEnd,
    };
    const availSecondDay = availCrossesMidnight
      ? { start: 0, end: adjAvailEnd }
      : null;

    const testFirstDay = {
      start: testStart,
      end: testCrossesMidnight ? 1440 : adjTestEnd,
    };
    const testSecondDay = testCrossesMidnight
      ? { start: 0, end: adjTestEnd }
      : null;

    // Check for overlap between all possible day segment combinations
    const firstDayOverlap = checkSegmentOverlap(availFirstDay, testFirstDay);

    const secondDayOverlap =
      availSecondDay &&
      testSecondDay &&
      checkSegmentOverlap(availSecondDay, testSecondDay);

    const crossDayOverlap1 =
      availSecondDay && checkSegmentOverlap(availSecondDay, testFirstDay);

    const crossDayOverlap2 =
      testSecondDay && checkSegmentOverlap(availFirstDay, testSecondDay);

    // If any segment combination overlaps, the ranges overlap
    const hasOverlap =
      firstDayOverlap ||
      secondDayOverlap ||
      crossDayOverlap1 ||
      crossDayOverlap2;

    setOverlaps(hasOverlap ?? false);
  }, [availableStartTime, availableEndTime, testStartTime, testEndTime]);

✅ Results
Using this approach, we can now correctly detect overlaps even when times cross midnight.

🔍 Final Thoughts
✅ This method accounts for all edge cases
✅ Handles time spans that cross midnight

If you’re building a scheduling system, booking app, or calendar tool, this technique will save you hours of debugging!

💬 What’s Next?
🛠️ Improve performance by memoizing calculations
📚 Use this logic in a backend API to validate time conflicts
Let me know your thoughts in the comments! 🚀

🎉 Happy Coding!

Managing Deeply Nested React Components: An Architectural Approach 🤓

SebasQuiroga — Fri, 21 Mar 2025 17:08:04 +0000

When working on React applications, deeply nested components can quickly become difficult to manage. Data flow, event handling, and validation can create unnecessary complexity if not structured properly.

In this article, we’ll explore an architectural pattern that ensures scalability, maintainability, and clarity when working with nested components. This pattern follows the single responsibility principle, keeping child components focused on their own logic while the parent component handles all external operations.

📌 Want to see it live? Check out the 👉 Demo

📌 Want to explore the full project? Check out the 👉 GitHub Repository

🏗️ The Problem with Deeply Nested Components
As React applications grow, components tend to become deeply nested. This often leads to:

Tightly coupled components — Child components handle operations they shouldn’t.
Difficult debugging — Business logic is scattered across multiple components.
Reduced reusability — Components become difficult to extract and reuse.

🎯 The Goal
We want to:

✅ Keep child components pure (only concerned with UI and internal state).
✅ Centralize logic in the parent component (handling external actions like saving to a database).
✅ Use a validation utility to ensure data integrity before saving.
🛠️ Implementing the Pattern
Parent Component: Handling All Operations
The parent component is responsible for: 1️⃣ Managing application state. 2️⃣ Validating data before saving. 3️⃣ Handling updates from child components.

Parent component

import { useCallback, useState } from "react";
import { toast } from "react-toastify";
import { Data } from "../data/Data";
import { Child1 } from "./child1";
import { Child2 } from "./child2";


export const Parent = () => {
  const [data, setData] = useState<Data | undefined>({
    child1: undefined,
    child2: undefined,
    grandChild: undefined,
  });

const isDataComplete = useCallback(
    (incomingData: Partial<Data> | undefined): incomingData is Data => {
      return (
        !!incomingData?.child1 &&
        incomingData?.child1.trim().length > 0 &&
        !!incomingData?.child2 &&
        !!incomingData?.grandChild
      );
    },
    []
  );

const onSave = useCallback(
    (data: Partial<Data> | undefined) => {
      if (!isDataComplete(data)) {
        toast("Please fill all fields first", { style: { color: "black", backgroundColor: "#f9b6af" } });
        return;
      }
      toast("You filled all your fields!", { style: { color: "black", backgroundColor: "lightgreen" } });
    },
    [isDataComplete]
  );

const onUpdate = useCallback(
    (incomingData: Partial<Data>) => {
      setData(prev => ({ ...prev, ...incomingData }));
    },
    []
  );

return (
    <>
      <Child1 data={data} onUpdate={onUpdate} />
      <Child2 data={data} onUpdate={onUpdate} onSave={onSave} />
    </>
  );
};

Child1 Component: Delegating Updates

The child component only manages its own input and delegates updates to the parent.

import { useState } from "react";
import { Data } from "../data/Data";

export const Child1 = ({ data, onUpdate }: { data: Data | undefined; onUpdate: (parentData: Partial<Data>) => void; }) => {
  const [child1Input, setChild1Input] = useState(data?.child1);

return (
    <>
      <label>Child 1 input</label>
      <input
        value={child1Input}
        onChange={(e) => {
          setChild1Input(e.target.value);
          onUpdate({ child1: e.target.value });
        }}
      />
    </>
  );
};

Child2 Component: Nested Child and Save Action

import { useState } from "react";
import { GrandChild } from "./grandChild";

export const Child2 = ({ data, onUpdate, onSave }) => {
  const [child2Input, setChild2Input] = useState(data?.child2);

return (
    <>
      <label>Child 2 input</label>
      <input
        value={child2Input}
        onChange={(e) => {
          setChild2Input(e.target.value);
          onUpdate({ child2: e.target.value });
        }}
      />
      <GrandChild onUpdate={onUpdate} data={data} onSave={onSave} />
    </>
  );
};

GrandChild Component: Uses delegated logic for button operation

import { useState } from "react";

export const GrandChild = ({ onUpdate, data, onSave }) => {
  const [grandChildInput, setGrandChildInput] = useState(data?.grandChild);

return (
    <>
      <label>Grandchild input</label>
      <input
        value={grandChildInput}
        onChange={(e) => {
          setGrandChildInput(e.target.value);
          onUpdate({ grandChild: e.target.value });
        }}
      />
      <button onClick={() => onSave(data)}>Save</button>
    </>
  );
};

Custom logic and parent logic

If a child or grandchild component needs to include custom logic before updating the parent, it can define a custom callback that applies its own logic first and then invokes the delegated parent operation. For example:

const customOnUpdate = (value: string, onUpdate: (data: Partial<Data>) => void) => {
  console.log("Custom logic before updating:", value);

  // Then execute parent logic
  onUpdate();

console.log("Custom logic after updating:", transformedValue);
};

🎯 Why This Works
✅ Separation of concerns — Child components handle only their own logic.
✅ Single source of truth — The parent component manages and validates data.
✅ Improved reusability — Any component can be reused independently.
✅ Better maintainability — Debugging and extending functionality is easier.

🚀 Happy Coding!

Creating a Webhook in ServiceNow: A Step-by-Step Guide 🔥

SebasQuiroga — Wed, 12 Feb 2025 20:25:35 +0000

Introduction

🌐 Webhooks are a powerful way to enable real-time integrations between ServiceNow and external systems. 🔄 Whether you're sending incident updates 🆘 or triggering external workflows ⚙️, webhooks help streamline automation 🤖.

In this guide, we'll walk through setting up a webhook in ServiceNow step by step 🛠️, covering everything from writing the script ✍️ to configuring the event registry 📜 and business rule 📌.

By the end, you'll have a fully functional webhook ✅ and the debugging skills 🕵️‍♂️ to troubleshoot issues effectively. 🚀

🔥 TL;DR

Whenever a new operation (Create 🆕 / Update ✏️ / Delete ❌ / Query 🔍) is performed on the Incidents table, we’ll:

1️⃣ Create a Business Rule 📌 that executes after the operation finishes (to grab the most up-to-date data).

2️⃣ Dispatch an Event 🚀 with two parameters:

Current Data 📦 (which is needed in theory but doesn't work well for extracting data).
sys_id 🆔 (a unique identifier for each record).

3️⃣ Write an Event Script 💻 that:

Uses sys_id to query the Incidents table.
Fetches the latest data 📅.
Sends it to an external consumer 🌍.

By the end, we’ll have a real-time data synchronization ⚡ and a fully functional webhook for external integrations! 🔗🚀

1️⃣ Registering the Event in the Event Registry

We need first create an event.

Steps:

Navigate to Plataform Analytics Administration > Data Collector > Event Registry.
Click New to create a new event.
Set Table to Incident [incident].
Add a description like Triggers a webhook when an incident is created or updated.
Click Submit to save the event.

2️⃣ Creating the Script Action to Send an HTTP Request

The core of our webhook is a Script Action, which will send an outbound HTTP request when triggered. Let's start by writing the script that will handle this operation.

Steps:

Navigate to System Policy > Events > Script Actions.
Click New to create a new script.
Set the Event name to match the one we'll register in the step above (e.g., incident.webhook).
Check the Active checkbox
Use the following script to send an HTTP request:

(function executeWebhook(event) {
    try {

        const consumerEndpoint = "https://YOUR_ENDPOINT";

        gs.info("🔥 Outbound Message");

        const sysId = event.parm1;

        var incidentTableRecord = new GlideRecord("incident");

        incidentTableRecord.get(sysId);

        incidentTableRecord.query();

        if (incidentTableRecord.next()) {

            const recordSysId = incidentTableRecord.getValue("sys_id");
            const shortDescription = incidentTableRecord.getValue("short_description");
            const description = incidentTableRecord.getValue("description")
            const date = incidentTableRecord.getValue("sys_created_on");
            const state = incidentTableRecord.getValue("state");
            const incidentId = incidentTableRecord.getValue("number")
            const priority = incidentTableRecord.getValue("priority");

            var requestBody = {
                shortDescription,
                recordSysId,
                date,
                state,
                incidentId,
                description,
                priority
            };

            gs.info("Sending Webhook Payload: " + JSON.stringify(requestBody));

            var restMessage = new sn_ws.RESTMessageV2();

            restMessage.setEndpoint(consumerEndpoint);
            restMessage.setHttpMethod('POST');
            restMessage.setRequestHeader('Content-Type', 'application/json');
            restMessage.setRequestBody(JSON.stringify(requestBody));

            var response = restMessage.execute();

            var responseBody = response.getBody();

            gs.info('✅ Webhook response: ' + responseBody);


        } else {
            gs.info("❌ No incidents found.");
        }

    } catch (error) {
        gs.error('Error sending webhook: ' + error.message);
    }

})(event);

Click Submit to save the Script Action.

3️⃣ Creating a Business Rule to Trigger the Webhook

With the event in place, we need a Business Rule to fire it when an incident is created or updated.

Steps:

Navigate to Activity Subscriptions > Adminsitration > Business Rules.
Click New.
Set Table to Incident.
Set When to After
Check Insert and Update checkboxes
In the Advanced section, add the following script, updating it the event name created.

(function executeRule(current, previous /*null when async*/) {
    gs.info("Executing Business Rule");
    gs.eventQueue("your.event.here", current, current.sys_id); // UPDATE YOUR EVENT HERE
})(current, previous);

Click Submit to save the Business Rule.

4️⃣ Time to create an incident 😏

Use REST API Explorer

Debugging and Troubleshooting

Check the System Logs 🔥

If your webhook isn't working, go to System Logs > All and search for:

Verify the Event is Triggering
Use REST API Explorer

Conclusion 🎉

By following these steps, you've successfully created a webhook in ServiceNow using a Business Rule, Event Registry, and Script Action. This setup enables real-time integration with external services and can be customized further based on your needs. 🚀

Let me know if you have any questions or need enhancements! Happy coding! 👨‍💻🔥

Managing Multiple GitHub Accounts (Without UI Interaction 😎)

SebasQuiroga — Thu, 23 Jan 2025 22:25:32 +0000

If you work with both personal and work-related projects hosted on GitHub, and you’re using the same machine to work on them, configuring Git to push to the correct GitHub account can be tricky. In this article, we’ll go through the process of setting up your SSH keys, configuring Git settings, and ensuring your repositories use the correct account for each git push

Step 1: Generate SSH Keys for each GitHub account
GitHub uses SSH keys to authenticate you. To work with multiple GitHub accounts, you’ll need to create separate SSH keys for each account.

Commands to generate SSH keys:
Open your terminal and run the following command to generate a new SSH key for your personal GitHub account:

ssh-keygen -t ed25519 -C "your-email@example.com"

When prompted for a file to save the key, specify a unique name, for example:

For personal GitHub account: [recommended_path]/id_ed25519_personal
For work GitHub account: [recommended_path]/id_ed25519_work

Repeat the process for your work GitHub account, but with a different file name:

ssh-keygen -t ed25519 -C "your-work-email@example.com"

Now, instead of manually copying the SSH public key to GitHub's UI, you can automatically copy it to the clipboard using pbcopy command:

For Personal GitHub account, run:

pbcopy < ~/.ssh/id_ed25519_personal.pub

This command copies the contents of your public key directly to the clipboard.

After running this command, you can simply add the public key to GitHub:

Go to GitHub.com > Avatar > Settings > SSH and GPG Keys.

Click New SSH Key and paste the copied key (it’s already in your clipboard).

Step 2: Configure SSH to use the correct keys

Now that you have SSH keys, you need to tell your Mac which key to use for each GitHub account. This is done via the ~/.ssh/config file.

nano ~/.ssh/config

Add the following configurations for both GitHub accounts:

# Personal GitHub Account
Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_personal

# Work GitHub Account
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work

These settings tell your machine to use the corresponding SSH key when you interact with GitHub based on the host name (github-personal or github-work).

Step 3: Configure Git to Use the Correct Remote URL

Instead of manually updating the remote URL by commands every time you clone a repository, we'll set this up directly in the .git/config file. This ensures you’re always using the right GitHub account for your repos.

In each of your repositories, you’ll need to update the .git/config file to point to the correct SSH host and remote URL.

Open your repository folder.
Open the .git/config file on your project folder:

nano .git/config

Add/update the [remote "origin"] section to use the correct SSH URL based on your GitHub account:

For personal projects, update the url to:

[remote "origin"]
    url = git@github-personal:your-username-from-repo/your-repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*

[user]
    name = "Your name"
    email = "your-email@example.com"

This ensures the repository uses the correct GitHub account for pushing and pulling code.

Step 5: Verify everything is set up correctly

To ensure that everything is working as expected, you can verify the configuration with the following checks:

To verify that your SSH keys are configured correctly, test the connection with GitHub:

For your personal GitHub account, run:

ssh -T git@github-personal

Step 6: Push code to GitHub

Now that everything is set up, you can push your code to the appropriate GitHub account based on the repository configuration.

For personal projects:

git push -u origin main

Git will automatically use the correct SSH key and GitHub account, as specified in your .git/config.

Happy coding! 🚀

I Built BeatApp for Better Productivity — Now I Need Your Feedback! 💡

SebasQuiroga — Fri, 03 Jan 2025 19:46:33 +0000

Have you ever felt frustrated 😤 with the limitations of traditional task management apps? You know, the ones where everything feels flat ➡️ and disconnected? Tasks are just listed out 📝, with no real context or understanding of how they relate to each other 🔄. As a result, productivity often feels like jumping between scattered tasks 🤯, without a clear view of the bigger picture 🧩.

Why I Started Building BeatApp:
After struggling with task management tools and productivity apps for over 5 years ⏳, I realized that the best tools should offer context 🧠 and connections 🔗 between tasks, not just endless checkboxes to tick off ✅. So, I decided to build something different — BeatApp, a desktop tool that goes beyond the basics. BeatApp helps you visualize tasks as part of a larger, interconnected workflow 🔄, tracks your productivity metrics, connects you with the community through a leaderboard, and helps you stay focused with a curated Spotify playlist to keep you in the zone 🎧. And soon, BeatApp will feature AI assistance to help you define manageable tasks more efficiently 🤖.

What’s Different About BeatApp?
Multidimensional Task Management 🧩: BeatApp lets you see tasks as interconnected nodes 🔗, with dependencies represented by edges. This way, you get a full view of how everything fits together 🧠, allowing you to make smarter decisions about what to tackle next 🏆.

Spotify Integration for Focus 🎶:
Music can be a game-changer when it comes to focus 🧘‍♂️. With BeatApp, you get a curated Spotify playlist that helps you stay in the zone 🎧.

Task Recommendations 🧠:
BeatApp helps you decide what to work on next, based on your priorities 📅.

Leaderboards and Stats 📈:
BeatApp tracks your progress 📊, showing how productive you've been over time 📅. There's even a daily leaderboard 🏅 for some friendly competition 🎮.

Join the Beta Testing!
Here’s where you come in! I’m looking for testers who are willing to try BeatApp, play around with it, and provide feedback. Do you have ideas for new features? Found any bugs? Or simply have thoughts on how to make BeatApp even better? I’d love to hear from you!

Check out the app here: Beatapp

Discord

Let’s shape this app together and take productivity to the next level 🚀.

Thanks for your help in making it better! 🙏

A Playful Guide to Publishing and Installing NodeJS Packages on GitHub Packages 🚀

SebasQuiroga — Sat, 25 Nov 2023 03:11:39 +0000

Publishing a NodeJS package to GitHub Packages is a really exciting journey. 🌌 In this short and whimsical article, we'll take you through the process of not just publishing your package but also installing it from another project with an extra dash of excitement! 🎉

1.Publish It to the GitHub Packages Constellation 📦

Once you've validated the awesomeness of your package through successful builds, packs, and seamless imports into other projects, it's time to elevate it to the GitHub Packages cosmos. 🌠

a. Update Your Package Manifest

Open your package.json and append the following snippet:

"publishConfig": {
  "registry": "https://npm.pkg.github.com/@YOUR_ORG_OR_GITHUB_PROFILE"
},

b. Let the GitHub Workflow Unfold

Now, let's add a dash of automation by introducing a GitHub workflow. Create a folder at the project's root: .github/workflows and save the file. If you don't have a creative name, we get you cover: publishingWorkflow.yml 😋.

name: Publishing My Awesome Package!
on:
  push:
    branches:
      - main
jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write 
    steps:
    - uses: actions/checkout@v3

    - name: Set up Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '20.x' 
        registry-url: 'https://npm.pkg.github.com' # GitHub Package Registry URL

    - name: Install dependencies
      run: npm install

    - name: Build
      run: npm run build # replace with your build command

    - name: Publish
      run: npm publish
      env:
        YOUR_ENV_AUTH_TOKEN_TO_WRITE_PACKAGES: ${{secrets.YOUR_ULTRA_SECRET_TOKEN}}

Need help creating the token? - Scroll to the end.

With a push to the main branch, watch the magic unfold: NodeJS setup, dependency installation, package building, and the grand finale—publishing to GitHub Packages! 🚀

2. Authenticated Ventures Beyond the Stars 🔐

To install your private package from another project, a touch of authentication is needed.

a. Craft a Github Token

Head to your GitHub lair, generate a token with read_package privileges, and copy its essence. (Do not forget to authorize the token if you are in an organization clicking the Configure SSO button) 🧙‍♂️

b. Enchant the .npmrc Incantation

Locate your global .npmrc file (probably in /users/your_user/.npmrc on MacOS) and inscribe a new line:

//npm.pkg.github.com/:_authToken=YOUR_TOKEN

This magical token instructs your local NPM to seek treasures in the npm.pkg.github.com repository, armed with the enchanted authentication. ✨

c. Specify the private NPM repository in your project

Add a new file in the parent folder of your project: .npmrc and add Github private registry:

@YourOrgOrProfile:registry=https://npm.pkg.github.com/

Bravo, you've mastered the celestial dance of publishing and installing on GitHub Packages! 🎉🚀

Obtaining Your Magical Githu Token

Navigate to your GitHub account. In the top-right corner, select your profile, and then proceed to Settings.
Scroll down to Developer settings located at the bottom of the page.
Within Developer settings, find the section titled Personal access tokens and enter the sub-section labeled Tokens (classic).
Generate a new token by following the provided steps. Be sure to select read:packages among the permissions.
In case you operate within an organization, exercise caution. After creating the token, click on the Configure SSO button to ensure proper organization authorization.

Async JS Patterns using Generator Functions

SebasQuiroga — Wed, 02 Feb 2022 14:15:34 +0000

We have already discussed some approaches to manage concurrency in JS, we have used callbacks, thunks (callbacks with some more bits), promises and in this article, we will talk about generator functions, conceptually speaking, this pattern is the foundation of the fancy async functions.

Have you probably imagined a JS function that we can pause and resume? It would be *pretty cool isn’t it? - unfortunately with all that *hurry of the JS engine to execute the fastest and easiest instructions, it seems quite impossible.

Luckily there were some nice guys that have already imagined it and have made that possible within the JS engine. Differently to the previous approaches, we will now manage concurrency by pausing and resuming the execution of instructions inside a special function ... the generator function.

If you haven’t heard about generator functions, this article from MDN can help you to better understand it.

Let’s remember the previous example, where we need to fetch some data mocked by setTimeouts in a sequential ordered manner.

function fetchAPI(rq, time) {
    const apiResponses = {
        'file1': 'First File',
        'file2': 'Second file'
    }

    setTimeout(function () {
        console.info(apiResponses[rq])
    }, time)
}

fetchAPI('file1' , 3000)
fetchAPI('file2' , 100)

// Second file
// First file

The output of the previous code is not what we initially wanted, we really need to force 😤 the JS engine to think sequentially and in an order manner.

Let’s code an intuitive example of the previous scenario using generator functions.

function fetchAPI(rq, time) {
    const apiResponses = {
        'file1': 'First File',
        'file2': 'Second file'
    }
    setTimeout(function () {
        console.info(apiResponses[rq])
        iterator.next({ rq: "file2", time: 500 }) 
// Send new data and pauses
    }, time)
}

function* generator() {
    while (true) {
        const object = yield 'objectReceived'
        yield fetchAPI(object.rq, object.time)
    }
}

const iterator = generator()
iterator.next() 
// Position the iterator in the first 'yield' and then pauses

iterator.next({ rq: "file1", time: 2000 }) 
// Send the data and then pauses

iterator.next() 
// Position the iterator again ready for receiving new data and pauses

// First File
// Second file

Visually speaking we could see some differences with conventional functions, first of all, when we call a generator functions we get back an iterator, it is pretty much like as the next object:

{value: currentValue, done: false/true}

That lets us go over each yield , blocking in a sequential ordered fashion and then pausing.

In the previous snippet we basically pause the function so that it waits until the file1 with 2000 ms is reached and then we resumed it so that it starts fetching file2 with 500ms (the easiest and preferred by JS engine).

Indeed we could have solved this in different ways as we did in the previous articles, some of them could have been even shorter and more beautiful, but the very idea behind this example is to show how to use it, so that you can decide which one is the perfect suit for your use-case. Every strategy for managing concurrency in JS brights more in some scenarios than in others, we need to first prove them and then choose.

Let’s do a powerful mix of generator functions + promises so that we approach this problem in a pretty more sophisticated way.

function fetchAPI(rq, time) {
    const apiResponses = {
        'file1': 'First File',
        'file2': 'Second file'
    }
    return new Promise((resolve) => {
        setTimeout(function () {
            resolve(apiResponses[rq])
        }, time)
    })
}
function runGenerator(g) {
    let it = g(), ret;

    (function iterate(val) {
        ret = it.next(val);

        if (!ret.done) {
  // Test the resolution of the promise
            if ("then" in ret.value) {
                // wait on the promise
                ret.value.then((data) => {
 // When the data is fetch || first promise yield is execute
                    iterate(data) 
// the pointer in the generator function moves to the next yield
                });
            }
        }
        // done
    }

    )();
}

runGenerator(function* main() {
    var result1 = yield fetchAPI('file1', 2000);
    console.info(result1)
    var result2 = yield fetchAPI('file2', 500);
    console.info(result2)
});

// First file
// Second file

The idea behind this, is to handle several asynchronous calls (returned as promises) in a orchestrated way (using runGenerator() function), we are fundamentally doing the same, but this time we let the runGenerator() function to iterate over the generator function main() itself and checking whenever those async calls are fulfilled.

Conceptually speaking, generator functions are the bases of the async functions. This new fancy API does what we saw in the previous examples but hiding some of the complexity of them in a pretty awesome manner.

Now let’s code the same example but this time using async functions.

async function fetchAPI(rq, time) {
    const resp = **await** new Promise((resolve) => {
        const apiResponses = {
            'file1': 'First File',
            'file2': 'Second File'
        }

        setTimeout(function () {
            resolve(apiResponses[rq])
        }, time)
    })
    return resp
}

fetchAPI('file1', 3000)
    .then(resp => {
        console.info(resp)
        return fetchAPI('file2', 100)
    }).then(resp => {
        console.info(resp)
    })

// First File
// Second File

That’s it. The fancy async function fetchAPI() waits until a promise resolves or rejects pausing the execution of the next instruction (in this case the return resp), when the promise resolves, the functions resumes and continues, behaving as synchronous, blocking and reasonable as we all love. Keep in mind that this works only for promise returned values

Finally, to end this series Async JS Patterns, let’s remember from where we have come, we initially started in the callback world, we go deeper revising thunks, then we jumped to promises, and finally we entered the awesome world of generator functions and async functions. I hope you have enjoyed this adventure, it was a really pleasure to me to share this knowledge with you, I would have loved to go beyond explaining in a more technical understanding and better view of this approaches in terms of performance, if you would like it too, please write me, and even if you are not interested, write me as well so we can get in touch 😎.

Async JS Patterns using Promises

SebasQuiroga — Wed, 02 Feb 2022 13:47:14 +0000

So far we have seen that the JS engine is always looking for executing the fastest(easiest) instructions in our code 🤪, leaving aside those lines such as setTimeouts, API calls, renderings that seem slow 😭. Having a solid understanding of the different mechanisms for dealing with this behavior is really useful.

Let’s image that there is a fancy new project in the company we are currently working on 🥳, as a Proof of Concept, the PM tell us to code a program that fetches some files from the Internet, these files can be quite heavy such as books with thousands of pages or pretty light files like recipes with a maximum of 2 pages, as the files API are not still available, the team suggests simulating this delay with setTimeouts 😎, but there is one mandatory requirement, the files have to be fetched in order 😏, the idea behind this is to offer a better user experience, so when a customer decides to download a book and then a recipe, these are downloaded in this particular order and not otherwise.

The first idea we come across with is as follows:

function fetchAPI(rq, time) {
    const apiResponses = {
        'file1': 'First File',
        'file2': 'Second file'
    }

    setTimeout(function () {
        console.info(apiResponses[rq])
    }, time)
}

fetchAPI('file1' , 3000)
fetchAPI('file2' , 100)

// Second file
// First file

The output was not as we want, JS engine is not executing in a sequential ordered manner 😵, as we really want it to 😤.

Intuitively speaking we could have easily inferred that fetchAPI() would first execute the setTimeout, wait until it finishes and then pass to fetch the next file, but it actually didn’t happen.

We really need a mechanism for dealing with the crazy way JS engine executes instructions, in the previous posts we studied how callbacks are a pretty initial strategy for this matter, however we ended up with an approach directing us to some inversion of control issues, lack of trust and some reasonability concerns.

Let’s try to think how we as humans are used to solve this problem in our daily lives.

Let’s imagine that after reading this article you write me an email 🤗 and we decide to meet up in person, so we can get in touch 🥳, we both like hamburgers and then we resolve to visit a quite nice place in the city, we go to the counter and order two delicious hamburgers, the lady hands us a ticket with the order 🎫, we sit down and wait, eventually we start smelling the delightful hamburgers and imagining eating it 🍔, finally we are called, we return the ticket and we get two scrumptious hamburgers. We might even not notice yet but the restaurant had a very nice method for serving lots of people concurrently 🤓; we as customers give instructions of how we want a product, they hand us a ticket (pretty much like a promise*), that particular piece of paper means we have the hamburgers, the restaurant will eventually (when the earlier orders are dispatched, like previous tasks) start cooking ours, they can have dozens and even hundreds of orders, but all customers are happy because that ticket is a *virtual** instantaneous hamburger that lets us reason about it.

Ideally there are two possible outcomes: either we all get the hamburgers🥳 or the restaurant run out of them 😱😭. The nice thing here is that whatever happens we are informed (inversion of control reverted) and then we can decide either buying another product or going to another place.

The ticket in the restaurant performs as a promise, a promise is way to represent a future value, as in the analogy, the promise can be somehow resolved or rejected but we are warned of either the case, which gives us again the control.

Let’s try to code once again the same requirement but this time using promises.

function fetchAPI(rq, time) {
    return new Promise((resolve) => {
        const apiResponses = {
            'file1': 'First File',
            'file2': 'Second File'
        }

        setTimeout(function () {
            resolve(apiResponses[rq])
        }, time)
    })
}

fetchAPI('file1', 3000)
.then( resp => {                  // Resolves first promise.
    console.info(resp)
    return fetchAPI('file2', 100) // Return a second promise.
}).then(resp => {                 // Resolves second promise.
    console.info(resp)
})

// First File
// Second File

Fundamentally speaking, we are still using callbacks, but promises behave pretty more awesomely, when we call a promise we give it the control over some business logic (such as fetching data, rendering, etc) similar to callbacks, but the interesting part is that promises give us back the control notifying us if the task could successfully be done or if the task failed, so that we can determine what to do in either the case, in other words, we are not blindly expecting a desired outcome, we can now prepare for no-matter-what the scenario can be.

We have now a more reasonable, reliable, and controllable mechanism for coordinating the nature concurrent way of behavior of JS engine.

Finally I want to write some notes for a correct use of the promises API:

For a correct chain of promises,

examplePromise1
    .then(resp1 => {
    ...                                   // Resolves the first promise.
    })
    .then(() => return examplePromise2)   // Returns the second promise.
    .then((resp2) => {
        ...                               // Resolves the second promise.
    })
    .then(() => return examplePromise3)   // Returns the third promise.
    .then((resp3) => {
        ...                               // Resolves the third promise.
    })

The snippet above is just a sketch to show you explicitly the importance of returning each promise so that the resolution of them are sequentially and controlled, otherwise, JS engine will execute those task crazily 🤪 as we don't want.

The correct error handling of promise rejections is through the reserved word catch, in a chain of promises one .catch() is enough for any rejection in any of the chain, as the following sketch:

examplePromise1
    .then(resp1 => {
    ...                                    
    })
    .then(() => return examplePromise2)   
    .then((resp2) => {
        ...                               
    })
    .then(() => return examplePromise3)   
    .then((resp3) => {
        ...                     
    })
    .catch(err => {
        throw new Error(err)        // This catch gathers any rejection in any of the three promises
    })

Once read and understood this article I encourage you to study some additional fancy features of the API such us Promise.race, Promise.all, Promise.any reference here.

References

[Book] - You Don’t Know JS Async & Performance
Promises MDN

Async JS Patterns using Thunks

SebasQuiroga — Tue, 01 Feb 2022 14:14:47 +0000

This is the second part of the series Async JS Patterns, in the previous post I wrote about callbacks and how they help us to sort some common programming puzzles such as concurrency. In this post we will talk about a slightly different approach of callbacks, thunks.

Let’s first revise an important concept behind thunks.

A closure is the combination of a function enclosed with references to its surrounding state (the lexical environment). MDN

Let’s check the example provided by MDN, (I intentionally changed some comments and lines for a better understanding).

function makeFunc() {
    var name = 'Mozilla';
    function displayName() {
        console.info(name);
    }
    return displayName;
}

var myFunc = makeFunc();
myFunc();   
// it executes the function displayName() 
// using all the private state (in this case the string) 
// from its parent function makeFunc()

As we can see in the previous snippet, a closure lets a function remembers the collection of states (similar to a conventional memory system) and play with them, it is very simple but applied in async tasks makes it very interesting.

Practical speaking a thunk is the returned function in a function, like in the next code:

function helloWorld() {
// Some private state
    return function thunk(cb){
                // We have access to all private state from helloWorld() - closure -
                // And aditionally we can use it as a mechanism for delaying execution
                // (check the comments at the end of this example)
                cb()
    }
}

let th = helloWorld()
th(cb) 
// Whenever the function helloWorld() has finished its instructions,
// we pass to the return function a callback with more instructions,
// resulting in a sequential flow!

The previous example is a taste of async thunks but let’s keep it simple, we will dig into async thunks in a while.

Technically speaking a thunk is a container around a collection of state, it is a function that returns an other function thus it has access to the parent private state (closure).

Let’s consider the next synchronous thunk:

function sumThunk(a, b) {
    return a+b
}

function commonFunction(){
    const a = 10 
    const b = 10  
    return sumThunk(a,b) //This returns a thunk function that make use of the parent private state, 
                         // everytime it is called, it will always remember this state.
                         // It acts like a container around a value(s), pretty similar to a token
}

const total = commonFunction()
console.info(total) // 20

Asynchronous thunks behave pretty similar, however we pass as parameter a function(callback) so whenever the value is ready (like the fetching of some data) it executes the function (resulting as a sequentially and blocking way of sorting asynchronous tasks).

Let’s code a program that fetches some data, but this time we will code it as intuitive as our brain would most likely sort it.

function fetchAPI(rq, time) {
    const apiResponses = {
        'file1': 'First File',
        'file2': 'Second file'
    }

    setTimeout(function () {
        console.info(apiResponses[rq])
    }, time)
}

function executer(rq, time) {
        fetchAPI(rq, time) 
}

let th1 = executer('file1' , 3000)
let th2 = executer('file2' , 100)

// Second file
// First file

The output of the previous example is not what we initially expected, we want the file1 to be fetched first and then the file2. The real problem here is with JS engine, because it is responsible for executing instructions as fast as possible without worrying about waiting for slow responses, so what happens here is that as the file1 needs 3 seconds to execute and the file2 just 100 seconds, the JS engine will choose the file2 execution first than the file1, contrary to what we really want.

Now let’s consider the next example using thunks for managing async tasks correctly (sequentially and blocking)

function fetchAPI(rq, time, cb) {
    const apiResponses = {
        'file1': 'First File',
        'file2': 'Second file'
    }

    setTimeout(function () {
        cb(apiResponses[rq]) // - function ready() - lazy executed!
    }, time)
}

function executer(rq, time) {
    // we return a thunk with the - function ready() - as a 'future' callback
    return function thunk(cb) {
        fetchAPI(rq, time, cb) 
    }
}

// We return the function of  - function executer() - in the variable th, 
// as it is a function we can pass a param(in this case a callback - function ready() ), 
let th1 = executer('file1' , 3000)
let th2 = executer('file2' , 100)

th1(function ready(salida){
    console.info(salida) 
    // When JS engine comes in this line the first task has completed, 
    // so now we launch the second one
    th2(function ready(salida) {
        console.info(salida)
    })
})

References

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures
https://app.codesmith.io/blog/thoughts-on-javascript-thunks
You Don’t Know JS Async & Performance

Async JS Patterns using Callback

SebasQuiroga — Tue, 01 Feb 2022 13:46:21 +0000

JavaScript, one of the most used computing programming languages in today's world [reference], very criticized for its simplicity compared with Java or C++, but unquestionably, this is precisely one of the characteristics that makes it as powerful and globally spread.

Along these series of managing JS concurrency, we will discuss about some of the weapons we should probably all have in our personal arsenal when developing in JS; the main objective of these series is precisely train you in the combat field using those weaponry.

It is important to highlight that even when there are new fancy ways of solving concurrency problems, each mechanism has it own advantages/disadvantage and use-cases.

In this first episode we will talk about callbacks, a pretty nice initial way of solving concurrent tasks.

JS engine behaves pretty similar to the electricity, it is always looking for the path with less resistance, it will jump anything that might seem slow (setTimeouts, API calls, rendering etc) and go crazy executing the fastest instructions unless we use mechanisms for dealing with it 😉 (such as callback, thunks, promises, generator functions, async functions).

Callbacks 🤔

It all comes from functional programming where some brilliant guys back in 1930 introduced what is know known as lambda calculus, this topic is deep enough to another article but let's continue.

Let's go over the next function, it basically expects two arguments and prints out the sum of those, pretty simple, isn't it?

function foo(a, b) {
    console.info(a + b); // 3
}
foo(1,2);

But what about sending the reference of a function instead of some variables? - what would happen?

// A function for sum
function sum(a, b){
    return a + b;
}

// A function that orchestrates
function foo(callback, a , b){
    return callback(a,b) // this line will call our sum() 
}

const resp = foo(sum, 1, 2) // we pass the reference of the function sum() and two numbers
console.info(resp); // 3

Oww we just chained functions in a pretty awesome way, so we could also add a new function subtract so that just changing the reference to the new function, we can either sum or subtract.

function sum(a, b){
    return a + b;        
}

// New Subtract function
function sub(a, b){
    return a - b;      
}

function foo(callback, a , b){
    return callback(a,b) // this line will call either sum() or sub()
}

const respSum = foo(sum, 1, 2);
const respSub = foo(sub, 1, 2);  // We can now subtract too!

console.info(` Sum:  ${respSum}` ); // 3
console.info(` Sub:  ${respSub}`); // -1

The Callback pattern is very used but it is even more powerful when regarding asynchronicity; hopefully our apps need to communicate with other APIs for fetching, saving, updating data, this brings some new players in the game; we need to play with the mess produced by the JS engine when trying to execute as many instructions as possible without worrying about
sequential/blocking execution and human reasonability; dear reader, this is what I call asynchronicity heartbreak.

You can copy, paste and execute the next code and you will see how the JS engine prints ‘Second Line’ first and then ‘First Line’; in the opposite order as we really want.

function fetchFoo() {
    setTimeout(() => {
        console.info('First Line')
    }, 2000)
    console.info('Second Line')
}
fetchFoo()

What is really happening is when the JS engine executes fetchFoo() it will first try to read and solve the first line but as the setTimeout is waiting 2 seconds it jumps to the next instruction and prints 'Second Line' first.

Theoretically speaking one way of solving this puzzle is manually passing asynchronous tasks as they were synchronous, so that the JS engine doesn't have any other branch of code to prioritize and as soon as it finishes we pass new tasks and so on. Let’s revise the next code.

// Chaining callbacks as a way of forcing sequential execution

function fooBar() {
    cb1()
    function cb1() {

        setTimeout(function () {
            console.info('First Line')
            cb2()
        }, 1000)

        function cb2() {
            console.info('Second Line')
        }
    }
}

fooBar()

We are basically forcing a link of consecutive instructions so that the JS engine doesn't even have to think an easier path to follow, it doesn’t have any more option that waiting 1 second and printing the ‘First Line’ and then the ‘Second Line’ as we originally wanted.

The next code is a cleaner and more beautiful approach using the same principle.

function fooBar(cb1) {
    setTimeout(function () {
                // The function cb1() expects another callback - the cb2()
        cb1(function cb2 () {
            console.info('Second Line')
        })
    }, 1000)
}

// The function cb1() will eventually read and execute another callback that is not still defined.
// We will eventually define it with the next sequential instructions.
fooBar(function cb1 (cb2) {
    console.info('First Line')
    cb2()
})

We are basically saying: hey JS engine, you know what? - I will pass to you another function in a moment, I can not pass it to you right now because you will try to execute it in a way I don't want, so don't worry, just go ahead with your business and I call you later. When the timer reaches the 1 second and the ‘First Line’ is printed, we pass to it a brand new code (with the string ‘Second Line’) to execute, this is basically known as lazy execution.

Callbacks are a mechanism for lazy execution.

As almost everything in life, there are some considerations that need to be carefully taken. When using callbacks we will need to agree with the inversion of control, giving the control of our program to somebody else. we have probably all have to invoke an external API using this mechanism and living the horror of expecting that API doesn't fail, simply because there is no way that API notifies us, so that, we can code an emergency exit, we basically loose the control of our program, Kyle Simpson said in a talk regarding callbacks:

"There's part of my program that I'm in control of executing. And then, there's another portion of my code that I'm not in control of executing."

There is another problem ... trust, let's imagine that somehow the setTimeout eventually start failing, sometimes instead of timing 1 second it continues to 100 seconds! - that is a really pain!! - our program will take much longer that what we initially expected, or even worse, image that it never stops !! - Callbacks lack of some sort of mechanism that notifies us when something goes wrong so that we can code an emergency exit and protecting our computer power.

A part of that. there is still another problem with callback, they don’t match our sequential blocking way of thinking, Kyle Simpson says in one of his talks: (paraphrasing):

Bugs arise when code doesn’t work as our brain does.

Our natural way of solving concurrency problems differ from the way callbacks work, we probably would need another pattern for solving asynchronous tasks that doesn’t force us neither to lose the control (inversion of control) of our programs nor the lack of trust when third party APIs are involved and by the way, a more *reason*able approach.

The real problem with callbacks is deeper than just the callback hell

In the next post we will talk about Thunks, a slightly different callback pattern.

References

[Book] You Don’t Know JS Async & Performance
MDN