DEV Community: Vardan Hakobyan

React Keys Demystified: When Using Index as a Key Isn’t That Bad

Vardan Hakobyan — Mon, 30 Sep 2024 12:07:18 +0000

As React developers, we’ve all heard the mantra: “Don’t use array index as a key!” It’s repeated so often that it’s become an unquestionable rule for many. But like many rules in programming, the reality is more nuanced. Today, we’re going to explore situations where using an index as a key might not be the cardinal sin it’s often made out to be.

Understanding Keys, Reconciliation, and the Render-Commit Cycle

Before we dive into the controversy, let’s refresh our understanding of what keys do in React and how they fit into the bigger picture.

The Reconciliation Process

React’s reconciliation process is at the heart of its efficiency. When a component’s state or props change, React creates a new virtual DOM and compares it with the previous one. This comparison, or “diffing,” allows React to minimize actual DOM manipulations, which are costly in terms of performance.

The Render-Commit Cycle

Render Phase: React calls your components to figure out what should be on the screen. It creates a new virtual DOM based on the current state and props.
Reconciliation: React compares the new virtual DOM with the previous one, identifying what has changed.
Commit Phase: React applies the identified changes to the actual DOM.

The Role of Keys

Keys play a crucial role in the reconciliation process. They help React identify which items in a list have changed, been added, or been removed. A key is a special string attribute that you need to include when creating lists of elements.

What Exactly Do Keys Solve?

Keys solve the problem of efficient list updates. When you have a dynamic list (items can be added, removed, or reordered), keys help React track which specific items have changed.

Without keys (or with poorly chosen keys), React might unnecessarily recreate DOM elements that haven’t actually changed, leading to performance issues and potential bugs with component state.

The Case for Using Index as a Key

Now, let’s look at why using an index as a key isn’t always bad. Consider this scenario:

const NumberList = ({ numbers }) => {
  return (
    <ul>
      {numbers.map((number, index) => (
        <li key={index}>{number}</li>
      ))}
    </ul>
  );
};

In this example, using the index as a key is perfectly fine if:

The list is static (items are not added, removed, or reordered).
The items in the list have no ids (otherwise we could use the id instead of the index).
The list is never reordered or filtered.

Under these conditions, the index is stable and using it as a key won’t cause any issues.

The Real Problem: Unstable Keys

The issue isn’t really about using the index itself, but about using unstable keys. An index becomes problematic when it doesn’t consistently refer to the same item. This happens when:

Items are added to or removed from the beginning or middle of the list.
The list is reversed or sorted.

In these cases, the index of each item changes, leading React to misidentify components and potentially cause bugs or unnecessary re-renders.

Conclusion

While it’s generally a good practice to use unique and stable identifiers as keys, dogmatically avoiding index as a key in all situations is unnecessary. Understanding the reconciliation process and the purpose of keys allows you to make informed decisions about when using an index is acceptable or even preferable.

Remember, the key rule (pun intended) is stability. As long as your key consistently refers to the same item across re-renders, whether it’s an id, a unique attribute, or yes, sometimes even an index, you’re on the right track.

So next time you reach for that index as a key, don’t feel guilty — just make sure you understand the implications and that it’s the right tool for your specific use case.

P.S. You can find more information on React docs.

If you want to stay updated with the latest JavaScript and software development news, join my Telegram channel: TechSavvy: Frontend & Backend.

Job Scams: How Developers Are Tricked into Running Data-Stealing Code, and How to Spot It

Vardan Hakobyan — Thu, 26 Sep 2024 09:45:47 +0000

I recently shared a story about a scam job posting on Codementor where the goal was to trick developers into running malicious code on their machines. Fortunately, I discovered the issue before executing the code, and the account of the job poster has since been suspended.

However, it turns out this wasn’t just a one-time occurrence. I received a similar request yesterday. The “client,” who was looking for a developer to add new features to his project, shared a private GitHub repository and asked me to run the project to verify that it worked correctly, as “it was last developed about three months ago.” When I checked the repository, I found the last commit was made just 18 hours ago. The one before that was indeed a few months old.

This was the first warning sign: The author, who did the last commit yesterday, didn’t run the code before/after the commit? The commit included changes to 89(!) files.

I tried to find out what was in that commit. The commit message was “Style js files” and was mostly about file formatting changes (as if someone ran prettier on the entire codebase). After looking into bunch of files, I didn’t find anything immediately suspicious.

Next, I checked the entry point of the application. The App.js file looked like a plain React component with routing and a simple useEffect — nothing dangerous there. While there could be malicious code buried deeper in the project, going through every file could take hours…

What I learned from my last experience is that if there is something malicious, it will most probably run when you start the app. Since I didn’t find anything suspicious in the top-level file, I decided to check what happens when I want run the app. So I opened package.json and inspected what’s in the scripts section. Here’s what I found:

"start": "npm run config && react-scripts --openssl-legacy-provider start || exit 1",
"build": "npm run config && react-scripts --openssl-legacy-provider build || exit 1",
...
"config": "node src/check_node_version.js",

That config script stood out, so I opened the check_node_version.js file.

At first glance, nothing seemed off — until I noticed the “Symbols” panel on the right side. Aha! Functions with cryptic names started showing up. But wait, where did these functions come from? The file is only 14 lines long… I clicked on one, and a mysterious ellipsis icon appeared at line 10, which looked empty at first.

Hmm, very strange. What if I check the DevTools - will it show anything else? Strange. Could there be hidden code? I checked the DevTools, and sure enough, more information appeared there. The DevTools revealed code that wasn’t visible on GitHub. I didn’t clone the repository, so I’m not sure if it would have been visible locally either. And here is what I found there:

And here is our hidden code! I’m not sure why it isn’t visible on GitHub, anyway I didn’t clone the code to my machine to see if it would be visible there.

The next thing to do is to try to understand what the code is doing. I deobfuscated it using Deobfuscator and ran it through Gemini to explain its functionality. Here is Gemin’s answer:

This code is obfuscated Javascript and it appears to be malicious. Here’s a breakdown of its functionality:

1. Function Definitions:

The code defines several functions with cryptic names (_0x11bb, _0xc5de3a, etc.). These functions are likely used to perform specific tasks within the script.

2. String Decoding:

The function _0x11bb seems to be responsible for decoding obfuscated strings. It takes two arguments: an encoded string and a key. The function uses the key to shift characters in the encoded string, revealing the original text.

3. File System Interaction:

The code utilizes functions from the fs module to interact with the file system. It can access, read, and copy files.

4. Browser Extension Data Collection:

Functions like _0x4574da and _0x589215 seem to target specific browser directories (Chrome, Firefox) and search for local storage files associated with extensions. It then attempts to read these files, potentially gathering sensitive data.

5. System Information Collection:

The code retrieves information about the system, including hostname, platform, home directory, and temporary directory.

6. Solana ID Extraction (Optional):

It checks for the presence of a file named id.json in the Solana configuration directory and attempts to read it if found.

7. Data Exfiltration:

The collected data (potentially browser extension data and system information) is uploaded to a remote server using the request library.

In summary, this code appears to be designed to steal data from web browsers, potentially including login credentials or other sensitive information stored in extensions. It also gathers system information and might attempt to extract data related to Solana cryptocurrency wallets.

It’s important to never run such scripts as they can compromise your system’s security.

Bingo! Once again, this attack involved stealing system information and browser data, along with targeting Solana files.

I first read about such scam attempts just a month ago. And in less than 2 weeks I personally encountered 2 similar attempts. This seems to be a growing trend of targeting developers to steal their information.

To help protect against these types of scams, I’ve put together a list of precautionary actions. If you have more ideas, feel free to add them in the comments!

How to Minimize Risk from Scam Attempts:

Check the repository. Look at the commit history. Does it contain just 1 or 2 commits pushing an entire codebase for a large application?
Examine critical files. Focus on entry files (like app.js or index.js) and `package.json. Be on the lookout for suspicious dependencies or scripts.
Use a Virtual Machine or Docker. If you’re uncertain about the code’s safety, run it in a VM or Docker container to isolate your main environment.

That’s it, stay cautious and safe!

P.S. For more context, you can read my previous article on a similar scam attempt.

If you want to stay updated with the latest JavaScript and software development news, join my Telegram channel: TechSavvy: Frontend & Backend.

Implementing the Fibonacci Sequence in JavaScript: Common Approaches and Variations

Vardan Hakobyan — Mon, 23 Sep 2024 16:21:27 +0000

As a developer, you’ve likely encountered the task of writing a function to calculate values in the Fibonacci sequence. This classic problem often appears in coding interviews, typically asking for a recursive implementation. However, interviewers may sometimes request specific approaches. In this article, we’ll explore the most common Fibonacci sequence implementations in JavaScript.

What is the Fibonacci Sequence?

First, let’s refresh our memory. The Fibonacci sequence is a series of numbers where each number is the sum of the two preceding ones. It starts with 0 and 1:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, …

Common Implementation Approaches

1. Recursive Approach

The most traditional request is for a recursive implementation:

function fibonacciRecursive(n) {
  if (n < 1) {
    return 0;
  }
  if (n === 1) {
    return 1;
  }
  return fibonacciRecursive(n - 1) + fibonacciRecursive(n - 2);
}

While straightforward, this approach isn’t performant for large values of n. On a MacBook Pro i9 with 16 GB RAM, calculating the 40th Fibonacci number took about 1.5 seconds:

console.time('Recursive');
fibonacciRecursive(40);
console.timeEnd('Recursive');

VM379:3 Recursive: 1521.569091796875 ms

Attempting to calculate the 50th number caused the Chrome tab to become unresponsive.

2. Recursive Approach with Caching (Memoization)

The next variation of this question is to improve performance by adding a caching mechanism to our recursive implementation:

function fibonacciCached(n, cached = {[0]: 0, [1]: 1}) {
  if (n < 1) {
    return 0;
  }
  if (n === 1) {
    return 1;
  }

  if (cached[n]) {
    return cached[n];
  }

  cached[n] = 
    fibonacciCached(n - 1, cached) + fibonacciCached(n - 2, cached);

  return cached[n];
}

This approach introduces a cached object with initial values for 0 and 1. For any given number, we first check if we've already calculated its Fibonacci value. If so, we return the cached result instead of recalculating it. Otherwise, we calculate that value and store it in cached.

The performance improvement is significant (due to the additional memory used, of course). Calculating the 40th Fibonacci number took ~0.02 ms:

console.time('Recursive, with caching');
fibonacciCached(40);
console.timeEnd('Recursive, with caching');

VM382:3 Recursive, with caching: 0.01806640625 ms

3. Iterative Approach with a for Loop

Another common variation is implementing the Fibonacci sequence using a for loop:

function fibonacciWithIteration(n) {
    if (n <= 0) {
        return 0;
    }
    if (n === 1) {
        return 1;
    }

    let prev = 0;
    let next = 1;
    let result = 1;

    for (let i = 2; i <= n; i++) {
        result = prev + next;
        [prev, next] = [next, prev + next];
    }
    return result;
}

This approach is much faster than the basic recursive method (the one without caching):

console.time('With iteration');
fibonacciWithIteration(40);
console.timeEnd('With iteration');

VM44:22 With iteration: 0.10107421875 ms

The iterative approach can handle very large input values efficiently:

console.time('With iteration');
const result = fibonacciWithIteration(1400);
console.log(result);
console.timeEnd('With iteration');

VM325:22 1.7108476902340223e+292
VM325:23 With iteration: 0.5830078125 ms

Bonus: Returning the Fibonacci Sequence as an Array

Interviewers might also ask you to return the entire Fibonacci sequence up to the n-th number as an array. Let’s implement this using both recursive and iterative approaches.

Recursive approach

function fibonacciSequence(n) {
  if (n === 0) {
      return [0];
  }
  if (n === 1) {
      return [0, 1];
  }

  const arr = fibonacciSequence(n - 1);
  const currentValue = arr[n - 1] + arr[n - 2];

  return [...arr, currentValue];
}

console.log(fibonacciSequence(5)); // [0, 1, 1, 2, 3, 5]

This function works as follows:

For 0 and 1, we return hardcoded arrays.
For other cases:

We get the sequence for the previous number and store it in arr.
We calculate currentValue by summing the last two values of arr.
We combine arr and currentValue in a new array and return it.

Iterative Approach

function fibonacciSequenceWithIteration(n) {
  if (n < 1) {
    return [0];
  }

  let prev = 0;
  let next = 1;
  const arr = [prev, next];

  for (let i = 2; i <= n; i++) {
    arr.push(prev + next);
    [prev, next] = [next, prev + next];
  }
  return arr;
}

console.log(fibonacciSequenceWithIteration(5)); // [0, 1, 1, 2, 3, 5]

This function works as follows:

If the input is 0, we return an array with only the element 0.
For other cases:

We initialize prev and next variables to store the previous and next values.
We create arr with initial values [0, 1].
We iterate from 2 to n, pushing the sum of prev and next to arr in each iteration.
We update prev and next values and continue to the next iteration.

Conclusion

While this article covers several common Fibonacci sequence implementations, it’s not an exhaustive list. If you’ve encountered other variations in interviews or your work, please share them in the comments!

Stay updated with the latest JavaScript and software development news! Join my Telegram channel for more insights and discussions: TechSavvy: Frontend & Backend.

Unveiling the Monty Hall Problem: A JavaScript Simulation

Vardan Hakobyan — Sat, 21 Sep 2024 06:42:09 +0000

Have you ever pondered the Monty Hall problem? This classic probability puzzle has baffled both mathematicians and casual thinkers for years. Today, we’re going to demystify this counterintuitive puzzle using the power of JavaScript.

The Monty Hall Problem: A Quick Recap

Imagine this scenario:

You’re on a game show facing three closed doors.
Behind one door lies a shiny new car; behind the other two, just goats.
You pick a door (let’s call it Door A), hoping for the car.
The host, Monty Hall, who knows what’s behind each door, opens another door revealing a goat.
Now, Monty offers you a choice: stick with Door A or switch to the remaining unopened door.

Here’s the million-dollar question: Should you switch doors or stay put? Does it even matter?

Surprisingly, the odds aren’t 50–50. If you switch, you’ll win the car 2/3 of the time! Sounds counterintuitive, right? Let’s prove it with code.

Setting Up Our JavaScript Simulator

First, let’s create a simple Node.js app. If you’re familiar with the process, feel free to skip this section.

Otherwise, follow these steps:

Open your terminal and navigate to your desired project folder.
Run these commands:

mkdir monty-hall-problem
cd monty-hall-problem

Now, create an entry file, where we will write the actual code:

touch index.js

That’s it! Now, open this file let’s start the actual coding!

Coding the Monty Hall Simulation

Let’s break down our simulation into manageable steps:

Model three doors
Randomly place the car behind one door
Simulate the player’s initial choice
Simulate Monty opening a door with a goat
Simulate choosing the remaining door when the player decides to switch
Calculate wins for both strategies: switching and staying

Let’s introduce a constant for the doors count so we won’t have the magic number 3 in our code.

const DOORS_COUNT = 3;

We’ll keep the win numbers in respective variables:

let winsWithoutDoorChange = 0;
let winsWithDoorChange = 0;

Let’s create a function that randomly generates an integer between 0 and given maxNumber:

const generateRandomNumber = (maxNumber) => {
  return Math.floor(Math.random() * maxNumber);
}

We have 3 doors, starting from index with 0, so maxNumber will be 2. Let’s randomly select our door with car and the one the player chose:

const doorWithCar = generateRandomNumber(DOORS_COUNT);
const chosenDoor = generateRandomNumber(DOORS_COUNT);

Then, we need to choose some door that the host will open. It must not be the one the player chose, and also must not be one with car. We can do that with this code (one of rare cases when do/while is actually appropriate):

do {
  openDoorWithGoat = generateRandomNumber(DOORS_COUNT);
} while ([chosenDoor, doorWithCar].includes(openDoorWithGoat));

Ok, now we have one door chosen by player and another open door with a goat. The player can change their decision and choose the last door. Let’s simulate it:

const newChosenDoor = [0, 1, 2]
      .find(door => ![chosenDoor, openDoorWithGoat].includes(door));

Here we iterate over an array of 3 elements (doors), and select the only one remaining (the door that is not selected and is not open). This is the new door that the player chooses.

All that remains is to check whether the player has won and increase the corresponding counter:

if (chosenDoor === doorWithCar) {
  winsWithoutDoorChange++;
}

if (newChosenDoor === doorWithCar) {
  winsWithDoorChange++;
}

That’s it! Let’s put this logic in a for loop and try iterating with different numbers. Remember, the more iterations, the more accurate the final result will be.

Here’s the complete code for our simulation:

const ATTEMPTS_COUNT = 1000_000;
const DOORS_COUNT = 3;

const generateRandomNumber = (maxNumber) => {
  return Math.floor(Math.random() * maxNumber);
}

const simulateMontyHall = (attempts) => {
  let winsWithoutDoorChange = 0;
  let winsWithDoorChange = 0;

  for (let i = 0; i < attempts; i++) {
    const doorWithCar = generateRandomNumber(DOORS_COUNT);
    const chosenDoor = generateRandomNumber(DOORS_COUNT);

    let openDoorWithGoat;

    do {
      openDoorWithGoat = generateRandomNumber(DOORS_COUNT);
    } while ([chosenDoor, doorWithCar].includes(openDoorWithGoat));

    const newChosenDoor = [0, 1, 2]
      .find(door => ![chosenDoor, openDoorWithGoat].includes(door));

    if (chosenDoor === doorWithCar) {
      winsWithoutDoorChange++;
    }

    if (newChosenDoor === doorWithCar) {
      winsWithDoorChange++;
    }
  }

  return {
    winsWithoutDoorChange,
    winsWithDoorChange,
  }
}

const {
  winsWithoutDoorChange,
  winsWithDoorChange,
} = simulateMontyHall(ATTEMPTS_COUNT);

const withoutChangeWinProbability = (winsWithoutDoorChange / ATTEMPTS_COUNT * 100).toFixed(2);
const withChangeWinProbability = (winsWithDoorChange / ATTEMPTS_COUNT * 100).toFixed(2);

console.log(
  `Without change, won ${winsWithoutDoorChange} out of ${ATTEMPTS_COUNT} attempts. Probability is ${withoutChangeWinProbability}%`,
);
console.log(
  `With change, won ${winsWithDoorChange} out of ${ATTEMPTS_COUNT} attempts. Probability is ${withChangeWinProbability}%`,
);

To start the program, simply run node index.js in terminal. You will have ~33.3% of wins if the player doesn’t change their initial choice, and ~66.6% of wins in case of change.

If you don’t want to create and run the program locally, here is a link to Codepen. Run it and check the results.

Hope you enjoyed it! If you have any notes, remarks or questions, please share them in the comments.

Prefer watching instead? Check out the video on YouTube.

Stay updated with the latest JavaScript and software development news! Join my Telegram channel for more insights and discussions: TechSavvy: Frontend & Backend.

When do (and don’t) children re-render in React?

Vardan Hakobyan — Thu, 19 Sep 2024 06:57:30 +0000

When writing React components, we always strive to keep optimization in mind. It’s always useful to know when unnecessary re-rendering occurs in our code, especially if we have heavy components in our app.

So let’s dive in and see what happens with child components when their parents re-render.

In most cases we use child components by their name. Let’s examine the following code:

import { useState } from "react";

const Parent = () => {
  const [number, setNumber] = useState(0);

  console.log('<Parent> renders');

  return (
    <div>
      Number is {number}
      <div>
        <button onClick={() => setNumber(prev => prev + 1)}>
          Increment
        </button>
      </div>
      <Child />
    </div>
  );
};

const Child = () => {
  // Some time-consuming logic
  console.log('<Child> renders');

  return (
    <div>
      <div>Child component</div>
    </div>
  );
};

const App = () => {
  return (
    <Parent />
  );
};

export default App;

Every time the button is pressed, the state of the <Parent /> component changes and it re-renders, which causes re-rendering <Child /> component as well.

How can we prevent unnecessary re-renders for the Child component? Let’s explore two approaches to achieve this.

Approach 1: Our friend React.memo

If we wrap the Child component into React.memo, the Parent’s re-render will not cause the Child to re-render.

Quick reminder — React.memo memoizes components, ensuring they are not re-rendered when their props remain unchanged.

import { memo, useState } from "react";

const Parent = () => {
  const [number, setNumber] = useState(0);

  console.log('<Parent> renders');

  return (
    <div>
      Number is {number}
      <div>
        <button onClick={() => setNumber(prev => prev + 1)}>
          Increment
        </button>
      </div>
      <Child />
    </div>
  );
};

const Child = memo(() => {
  // Some time-consuming logic
  console.log('<Child> renders');

  return (
    <div>
      <div>Child component</div>
    </div>
  );
});

const App = () => {
  return (
    <Parent />
  );
};

export default App;

Approach 2: Using {children} prop

We can use {children} prop to achieve the same result. Let’s see it in action.

{children} prop allows the parent component to accept and render its children components dynamically.

import {useState} from "react";

const Parent = ({children}) => {
  const [number, setNumber] = useState(0);

  console.log('<Parent> renders');

  return (<div>
    Number is {number}
    <div>
      <button onClick={() => setNumber(prev => prev + 1)}>
        Increment
      </button>
    </div>
    {children}
  </div>);
};

const Child = () => {
  // Some time-consuming logic
  console.log('<Child> renders');

  return (
    <div>
      <div>Child component</div>
    </div>
  );
};

const App = () => {
  return (
    <Parent>
      <Child />
    </Parent>
  );
};

export default App;

Using children prop here makes the code easier to follow, and also removes extra clutter coming from memo.

While these two approaches help us remove unnecessary re-rendering child components, bear in mind that we don’t need to blindly optimize everything. If our component doesn’t involve heavy calculations or other performance bottlenecks, we usually shouldn’t prematurely optimize it. Always strive to keep components small and easy to follow, and optimize them only when necessary.

Thanks for reading! If you have any notes, remarks or questions, please share them in the comments.

Stay updated with the latest JavaScript and software development news! Join my Telegram channel for more insights and discussions: TechSavvy: Frontend & Backend.

Mastering Email-Ready HTML: Automated Style Inlining with Tailwind CSS

Vardan Hakobyan — Wed, 18 Sep 2024 07:17:38 +0000

In the world of email development, ensuring consistent styling across various email clients is a significant challenge. Email clients are notoriously inconsistent in their CSS support. Many strip out <style> tags or ignore external stylesheets. So ensuring consistent appearance across various email clients often requires inline CSS styles. This requirement can conflict with modern development practices, especially when using utility-first CSS frameworks like Tailwind.

Recently, while working on a project that required sending various emails to users, I faced this exact dilemma. We were using Tailwind for our main application, and I wanted to maintain this efficient workflow for our email templates as well. However, the need for inline styles in emails posed a significant hurdle.

I considered several approaches:

Creating email templates with inline styles from the start.
- Pros: Guaranteed compatibility with email clients.
- Cons: Time-consuming to write and maintain, prone to errors, and incompatible with Tailwind.
Using online converters to transform Tailwind-styled templates into inline styles. Then, save the HTML with inline styles as a separate file to be sent via email.
- Pros: Allows use of familiar Tailwind syntax during development.
- Cons: Requires keeping two versions of each template (original and converted).
Utilizing an npm package to convert templates to inline styles at runtime.
- Pros: It’s time-efficient and allows me to maintain only one version of each email template using Tailwind.
- Cons: I did come across some packages like tailwind-to-css or tw-to-css, but while they have their merits, I encountered the following issues:
  
  ❌ tailwind-to-css generates random class names in the result HTML
  ❌ tw-to-css requires calling a converter function for every Tailwind class usage.

After evaluating these options and finding existing tools lacking, I decided to implement a custom solution. In this article, I’ll guide you through the development of a TypeScript module that automates the process of inlining Tailwind classes for email-ready HTML.

I want to highlight that the code actually runs on the Node.js server, so I aimed to use the bare minimum from the frontend world necessary to make the logic work.

Actual implementation

The main logic is resided in makeStylesInline function:

export const makeStylesInline: TMakeStylesInline = async (
  templatePath,
  data,
) => {
  const templateSource = fs.readFileSync(templatePath, 'utf8');
  const template = Handlebars.compile(templateSource);
  const html = template(data);
  return inlineStyles(html);
};

This function takes a template path and optional data, compiles the template with Handlebars, and processes the resulting HTML to inline styles.

Harnessing the Power of Tailwind CSS

A key component is the processTailwindCSS function, which applies Tailwind CSS to our HTML:

const processTailwindCSS = async (html: string): Promise<string> => {
  const tailwindConfig = {
    content: [{ raw: html, extension: 'html' }],
    corePlugins: {
      preflight: false,
    },
  };

  const result = await postcss([
    tailwindcss(tailwindConfig),
    autoprefixer,
  ]).process('@tailwind components; @tailwind utilities;', {
    from: undefined,
  });

  return result.css;
};

This function sets up a minimal Tailwind configuration and uses PostCSS to generate the necessary CSS.

Simplifying and Optimizing CSS for Emails

Given the limited CSS support in email clients, the simplifyColors function optimizes the generated CSS:

const simplifyColors = (css: string): string => {
  const generalSimplifications = css
    .replace(/rgb\(([^)]+)\) \/ var\(--tw-[^)]+\)/g, 'rgb($1)')
    .replace(
      /rgba\(([^,]+),([^,]+),([^,]+),var\(--tw-[^)]+\)\)/g,
      'rgba($1,$2,$3,1)'
    )
    .replace(/var\(--tw-[^)]+\)/g, '1')
    .replace(/--tw-[^:]+:[^;]+;/g, '');

  return generalSimplifications.replaceAll(
    /(rgba?\(\d+\s+\d+\s+\d+\s*\/.*\))/g,
    (match) => rgbToHex(match)
  );
};

This function removes Tailwind-specific CSS variables and converts RGB colors to hexadecimal for better email client support.

The Art of Style Inlining

For the actual inlining process, we use the juice library:

const inlineStyles = async (html: string): Promise<string> => {
  const tailwindCss = await processTailwindCSS(html);
  const simplifiedCss = simplifyColors(tailwindCss);

  return juice(html, {
    extraCss: simplifiedCss,
    applyStyleTags: true,
    removeStyleTags: true,
    preserveMediaQueries: true,
    preserveFontFaces: true,
    preserveImportant: true,
    inlinePseudoElements: true,
  });
};

This function processes the HTML with Tailwind, simplifies the resulting CSS, and then uses juice to inline the styles. It preserves important structures like media queries and font faces.

Handling Dynamic Content with Handlebars

The solution integrates Handlebars for template compilation, allowing for dynamic content insertion:

const templateSource = fs.readFileSync(templatePath, 'utf8');
const template = Handlebars.compile(templateSource);
const html = template(data);

This approach enables the use of placeholder values in email templates, enhancing flexibility and reusability.

Conclusion

This TypeScript code offers an automated solution for generating email-ready HTML with inlined styles. By leveraging Tailwind CSS, PostCSS, and careful CSS optimization, it significantly streamlines the email development process. The result is consistently styled, cross-client compatible email HTML, generated with minimal manual intervention.

For developers looking to improve their email development workflow, this solution provides a robust starting point. It combines the utility-first approach of Tailwind CSS with the practicality of automated style inlining, all while maintaining the flexibility needed for dynamic email content.

For the full source code and more detailed implementation, visit the GitHub repository.

It’s important to note that this is version 1 of the solution, and as such, it may not cover all possible use cases or have all desired features. There’s always room for improvement and expansion, and I welcome feedback from developers who try this solution in their projects.

Thanks for reading! If you have any question or need some clarification, feel free to reach out.

Stay updated with the latest JavaScript and software development news! Join my Telegram channel for more insights and discussions: TechSavvy: Frontend & Backend.

Beware of Malicious Code: A Developer’s Experience with a Suspicious Request

Vardan Hakobyan — Tue, 17 Sep 2024 19:15:24 +0000

I’ve been doing mentoring and freelancing on Codementor for a while now. Recently, I applied for a project titled “Front-end Design Developer (React.js, Three.js)”. The client asked me to install their code locally and “fix the problem,” after which they’d set up a call with their CTO. They shared a Bitbucket link to their codebase.

So, I cloned the repository and ran npm install, but it failed due to a React version mismatch. I let the client know about the issue and asked if fixing the installation error was the main goal of this request. The error was apparently unexpected for him too, and he suggested running the install with the --force flag. He then said that once I did that, he’d explain what needed to be fixed.

This is when things started to feel suspicious.

I took a closer look at the files and found something odd — an obfuscated file named error.js, which was imported into backend/app.js.

Since it was an immediately invoked function expression (IIFE), it would execute as soon as it was imported. This, combined with the client’s refusal to provide any further details, raised major red flags.

I decided to report the situation to Codementor’s support team for further investigation. Meanwhile, the client kept insisting that I proceed with the installation, promising he’d “guide me” through the process afterward.

I had heard of scammers tricking developers into installing malicious code under the guise of fixing a bug. During the installation or run phase, these apps can search for sensitive data like cryptocurrency wallet information on your device, leading to potential theft.

And, guess what? A smart person on Reddit dug into the code of error.js file with the help of Gemini, and it turns out it is indeed malicious. It collects user data, crypto wallet information (Exodus), system data, and sends it to a remote server.

This is the detailed response from Gemini:

Data Theft:
The script focuses on stealing browsing data from various browsers (Chrome, Brave, Opera, Firefox) and cryptocurrency wallet information (Exodus). It achieves this by:

Identifying browser extension and profile folders.
Searching for specific files within those folders (likely containing browsing history, cookies, etc.).
Extracting the content of those files.
Sending the extracted data to a remote server controlled by the attacker.

Obfuscation:

The script uses various techniques to obfuscate its code and make it harder to understand:

Base-decoding for strings.
Self-referential tricks.
Closures to limit function execution.

Overall, this script is malicious and should not be run. It can steal sensitive information from your computer and send it to an attacker. If you suspect this script might be running on your system, it's crucial to take immediate action.

For the first time in my life I’m happy that the npm install command failed 😅 As I didn't run the code, I don’t think any harm was done. But I’ve definitely learned a lesson: never install code from strangers without inspecting it first (something I admittedly didn’t do well enough this time). As someone on Reddit wisely pointed out, a good practice is to always run unfamiliar code on a virtual machine to protect your system.

Stay safe, and be cautious when dealing with unvetted code!