DEV Community: Accreditly

How to use Tailwinds `safelist` to handle dynamic classes

Accreditly — Fri, 23 Aug 2024 09:25:00 +0000

Tailwind CSS is a popular utility-first CSS framework that allows developers to create custom designs quickly and efficiently. By default, Tailwind CSS generates a wide range of utility classes, which can lead to large file sizes. To address this issue, Tailwind CSS comes with a built-in feature called PurgeCSS that removes unused styles from the production build, making the final CSS file smaller and more performant. However, this automatic removal may sometimes cause issues when certain styles are used dynamically or conditionally in your application. In this article, we'll dive deep into the safelist feature in Tailwind CSS, learn how to whitelist specific styles, and explore various scenarios where using safelist can be helpful.

1. Understanding PurgeCSS in Tailwind CSS

PurgeCSS is a powerful tool that scans your project files for any class names used and removes the unused ones from the final CSS file. This significantly reduces the size of the generated CSS, making your application load faster.

By default, Tailwind CSS includes PurgeCSS configuration that scans your HTML, JavaScript, and Vue files for any class names. You can easily tweak what files are picked up within the content array of the config file.

In some situations, you might need to prevent specific styles from being removed, even if they're not detected in your files. This is where the safelist feature comes into play.

2. Introducing Safelist

Safelist is a feature in Tailwind CSS that allows you to whitelist certain styles so they don't get removed during the purging process. This is particularly useful when you have dynamic class names generated through JavaScript or applied based on user interaction. Another very common use-case for safelist is when colors or styles are driven from a CMS or backend framework. One such example might be a system that allows a website admin to edit the color of a category in a CMS, which in turn changes the color of the nav items for that category. Tailwind won't see the actual class name as the file will contain server-side code that outputs the color.

By adding these class names to the safelist, you ensure that they will always be included in your final CSS file, regardless of whether PurgeCSS can find them in your project files or not.

3. Configuring Safelist in `tailwind.config.js`

To configure the safelist in your Tailwind CSS project, you need to modify the tailwind.config.js file. The safelist is an array of class names that you want to keep in your final CSS file, even if they're not found in your project files. Here's an example of how to add class names to the safelist:

// tailwind.config.js
module.exports = {
  content: [
    // your content files here
  ],
  safelist: [
    'bg-red-500', 
    'text-white', 
    'hover:bg-red-700'
  ],  
  // other configurations
};

In this example, the bg-red-500, text-white, and hover:bg-red-700 classes are added to the safelist. These classes will always be included in your final CSS file, even if PurgeCSS doesn't find them in your project files.

4. More advanced configurations

If you have a lot of classes to manage within safelist, perhaps due to multiple colors and the need to support variants/modifiers such as :hover, :focus, :active and dark: then it can quickly become very challenging to manage these within safelist. The list will become huge very quickly.

That's where patterns come in. Tailwind support regex within the safelist:

safelist: [
  {
    pattern: /from-(blue|green|indigo|pink|orange|rose)-200/
  },
  {
    pattern: /to-(blue|green|indigo|pink|orange|rose)-100/,
  },
],

With these 2 entries we are effectively adding 12 classes. from-{color}-200 and to-{color}-100, where {color} is all of the colors in the list. It makes it much easier to manage the lists. Remember that tailwind.config.js is just a JavaScript file, so you can manage variables at the top of the file if you're managing lists of colors that are repeated heavily.

It's also possible to define variants for everything within the list without needing to explicitly list them in regex:

safelist: [
  {
    pattern: /text-(blue|green|indigo|pink|orange|rose)-(600|400)/,
    variants: ['hover'],
  },
  {
    pattern: /from-(blue|green|indigo|pink|orange|rose)-200/
  },
  {
    pattern: /to-(blue|green|indigo|pink|orange|rose)-100/,
  },
],

5. Safelist Examples and Use Cases

There are several scenarios where using the safelist feature can be helpful:

Dynamic class names: If you're generating class names dynamically based on some data or user input, PurgeCSS may not detect these classes and remove them from the final CSS file. By adding these dynamic classes to the safelist, you can ensure they're always available in your application.

// Example of a dynamic class name based on user input
const userInput = 'success'; // This value might come from an API or user input
const alertClass = `alert-${userInput}`;

// Generated class name: 'alert-success'

In this example, the alertClass variable generates a class name based on user input or data from an API. Since PurgeCSS can't detect this dynamic class name, you should add it to the safelist in your tailwind.config.js file.

Conditional styles: If you have styles that only apply under specific conditions, such as a dark mode or a mobile view, you can use the safelist to ensure those styles are always included in your final CSS file.

// Example of a conditional style based on a media query
@media (max-width: 767px) {
  .hidden-mobile {
    display: none;
  }
}

In this example, the hidden-mobile class is only applied when the viewport width is less than 768 pixels. Since this class might not be detected by PurgeCSS, you should add it to the safelist in your tailwind.config.js file.

6. Best Practices for Safelisting

When using the safelist feature in Tailwind CSS, keep the following best practices in mind:

Only add classes to the safelist that are truly necessary. Adding too many classes can bloat your final CSS file and negate the benefits of PurgeCSS.
If you have many dynamic class names or a complex application, consider using a function or regular expression to generate the safelist array. This can help keep your configuration cleaner and more maintainable.
Test your production build to ensure that all required styles are included. This can help you catch any issues early on and avoid surprises when deploying your application.

Summary

The safelist feature in Tailwind CSS provides a powerful way to whitelist specific styles and ensure they are included in your final CSS file, even if they are not detected by PurgeCSS. By understanding how to configure the safelist and use it effectively in various scenarios, you can make your Tailwind CSS projects more robust and maintainable. Remember to follow best practices when using the safelist to ensure your final CSS file remains lean and performant.

Feel free to look over the Tailwind Docs on Safelist usage.

Send email from WordPress the right way

Accreditly — Tue, 20 Aug 2024 09:14:46 +0000

Sending emails is a critical feature for many WordPress websites, whether it’s for account confirmations, notifications, or customized alerts. While many developers might default to using PHP’s mail() function, WordPress offers more robust and reliable alternatives. Let's explore the best practices for sending both plaintext and HTML emails within WordPress.

Why Avoid PHP’s `mail()` Function?

While PHP’s mail() function is straightforward, it has several drawbacks, particularly in terms of flexibility and reliability. It lacks support for SMTP authentication, which can lead to emails being flagged as spam. WordPress's built-in functions are designed to overcome these limitations, offering better formatting options and more consistent delivery rates.

Sending Plaintext Emails with WordPress

WordPress makes it easy to send plaintext emails using the wp_mail() function, which is more versatile than PHP’s native mail() function.

Here’s a basic example of how you can use wp_mail():

$recipient = 'user@example.com';
$subject = 'Welcome to Our Platform!';
$body = 'Thank you for joining us.';
wp_mail($recipient, $subject, $body);

If you need to add headers, such as a custom "From" address or "Reply-To," you can do so with an array:

$headers = array('From: Support Team <support@example.com>', 'Reply-To: support@example.com');
wp_mail($recipient, $subject, $body, $headers);

This approach ensures that your emails are sent with the correct headers, improving deliverability and reducing the likelihood of your emails being marked as spam.

Crafting HTML Emails in WordPress

If you want to send emails that are more visually engaging, such as newsletters or account information emails, HTML is the way to go. To send HTML emails in WordPress, you’ll need to set the content type to text/html. This can be achieved by using the wp_mail_content_type filter.

Here’s an example:

function set_html_mail_content_type() {
    return 'text/html';
}
add_filter('wp_mail_content_type', 'set_html_mail_content_type');

$recipient = 'user@example.com';
$subject = 'Your Account Information';
$body = '<html><body>';
$body .= '<h1>Welcome to Our Platform!</h1>';
$body .= '<p>Here are your account details.</p>';
$body .= '</body></html>';

wp_mail($recipient, $subject, $body);

// Reset content type to avoid affecting other emails
remove_filter('wp_mail_content_type', 'set_html_mail_content_type');

In this example, we first define a function to set the content type to HTML and then add it as a filter. After sending the email, the filter is removed to ensure that subsequent emails are not inadvertently sent as HTML.

For a more in-depth discussion on the best practices for sending emails from WordPress, including additional code examples and troubleshooting tips, check out our full article here.

Enhance Your WordPress Skills

If you're looking to deepen your understanding of WordPress, including how to handle email functionality more effectively, consider pursuing our WordPress Development Certification. It’s a comprehensive program designed to take your skills to the next level, covering everything from basic setup to advanced customization techniques.

The Differences Between "Test Coverage" and "Code Coverage"

Accreditly — Thu, 13 Jun 2024 08:06:54 +0000

As developers, we often hear terms like "test coverage" and "code coverage" thrown around in discussions about software quality. While they may sound similar, they represent different aspects of testing and development. Understanding the nuances between these two concepts is essential for improving code quality and ensuring robust software.

In this article, we’ll delve into what test coverage and code coverage mean, their importance, how they differ, and how you can effectively use them to enhance your development process.

Understanding Test Coverage

Test coverage is a metric that helps us understand how much of our application has been tested. It focuses on the completeness of the testing effort and is usually expressed as a percentage. Test coverage metrics can include:

Ensuring all user requirements have corresponding test cases, known as 'requirements coverage'.
Verifying that all functions or methods are tested, known as 'functional coverage'.
Confirming that every branch (e.g., if-else conditions) in the code has been tested, known as 'branch coverage'.

Why Test Coverage Matters

Test coverage helps identify untested parts of your application, pointing out areas that may need more thorough testing.
By ensuring all aspects of your application are tested, you can catch bugs early, leading to higher quality software.
High test coverage can give developers and stakeholders confidence that the application has been thoroughly vetted. This is especially true when introducing new developers to the project who may not understand some intricacies.

Measuring Test Coverage

Tools like JUnit for Java, NUnit for .NET, and pytest for Python, PHPUnit and the newer Pest for PHP provide features for measuring test coverage. These tools generate reports that show which parts of the application were executed during tests, helping developers identify untested sections.

Here's a simple example using pytest in Python:

# test_example.py

def add(a, b):
    return a + b

def test_add():
    assert add(1, 2) == 3
    assert add(-1, 1) == 0

# To run the test and measure coverage
# Use the following command:
# pytest --cov=.

The pytest-cov plugin generates a report showing the percentage of code covered by the tests.

Understanding Code Coverage

Code coverage, on the other hand, measures the extent to which your code has been executed. It's about ensuring that your codebase has been thoroughly exercised by tests. Key metrics for code coverage include:

The percentage of lines of code executed, known as 'line coverage'.
The percentage of executable statements run, known as 'statement coverage'.
The percentage of possible execution paths tested, known as 'path coverage'.
The percentage of functions executed, known as 'function coverage'.

Why Code Coverage Matters

Code coverage can help identify dead or redundant code that’s never executed, allowing you to clean up your codebase.
Well-covered code is often easier to maintain because it’s more likely to have fewer hidden bugs.
High code coverage ensures that changes or refactors don’t introduce new bugs since most paths and lines are tested.

Measuring Code Coverage

Popular tools for measuring code coverage include Istanbul for JavaScript, Jacoco for Java, and coverage.py for Python and PHPUnit (with XDebug, PCOV and phpdbg support) for PHP. These tools integrate with CI/CD pipelines to ensure continuous monitoring of code coverage.

Here's an example using coverage.py with a Python script:

# example.py

def multiply(a, b):
    return a * b

def divide(a, b):
    if b == 0:
        raise ValueError("Cannot divide by zero")
    return a / b

# test_example.py

import pytest
from example import multiply, divide

def test_multiply():
    assert multiply(2, 3) == 6

def test_divide():
    assert divide(10, 2) == 5
    with pytest.raises(ValueError):
        divide(10, 0)

# To run the coverage report
# Use the following command:
# coverage run -m pytest
# coverage report

The coverage tool will produce a report showing how much of the code has been executed during the tests.

Key Differences Between Test Coverage and Code Coverage

Focus

Test Coverage: Focuses on the extent to which the testing suite covers the application's functionality, requirements, and conditions.
Code Coverage: Concentrates on the extent to which the actual lines of code have been executed.

Measurement

Test Coverage: Measures how well the tests cover the requirements and functionality of the application.
Code Coverage: Measures how well the tests execute the code itself, identifying which lines or branches have been run.

Purpose

Test Coverage: Ensures all user scenarios and requirements are tested.
Code Coverage: Ensures the written code is exercised and validated, uncovering dead or untested code.

Using Test Coverage and Code Coverage Together

While both metrics provide valuable insights, relying solely on one can be misleading. High test coverage doesn't guarantee that all the code has been executed, and high code coverage doesn’t mean all functional requirements are tested. Combining both gives a more comprehensive view of your testing effectiveness.

Showing Off Coverage

If you run an open source project (or even closed source, I suppose), it is common to show badges on the README.md file of your project that show off the coverage of your project. Check out the very popular repo-badges GitHub repo for a bunch of examples.

Example Workflow

Write Tests: Write comprehensive tests covering all functional requirements and edge cases.
Measure Test Coverage: Use tools like pytest or JUnit to measure and report on test coverage.
Measure Code Coverage: Use tools like coverage.py or Istanbul to measure code execution.
Combine Reports: Analyze combined reports to ensure all aspects are covered.
Refactor and Improve: Refactor code and tests based on coverage insights to improve overall quality.

DRY: What is it and how to implement it. Don't Repeat Yourself

Accreditly — Tue, 07 May 2024 13:44:35 +0000

The DRY (Don't Repeat Yourself) principle is a key concept in software development that focuses on reducing code duplication and improving maintainability. By following the DRY principle, developers can create cleaner, more efficient, and less error-prone codebases. In this article, we will discuss the importance of the DRY principle and illustrate its application in JavaScript with two practical examples.

If you're looking for an example of writing DRY code then check out our article about safelist classes in Tailwind, which rewrites the ruleset to make them DRY.

Section 1: Understanding the DRY Principle

The DRY principle states that each piece of logic in a codebase should have a single, unambiguous representation. In other words, you should avoid duplicating code and extract repetitive parts into reusable components or functions. This approach ensures that when you need to make changes or fix bugs, you only have to do it in one place, making your code more maintainable and less prone to errors.

Section 2: Benefits of the DRY Principle

Improved maintainability: With less duplicated code, it is easier to understand, modify, and extend your codebase.
Reduced likelihood of bugs: By centralizing logic, you reduce the chances of introducing inconsistencies and errors when updating your code.
Enhanced readability: DRY code is generally more concise and easier to read, making it simpler for other developers to understand and work with your code.
Easier debugging: When logic is centralized, it's simpler to track down and fix issues, as you only need to investigate one location instead of multiple instances of the same logic.

Section 3: DRY Principle in JavaScript – Example 1

Consider the following code that calculates the price of items after applying a discount:

Before applying DRY:

function getPriceAfterDiscountA(price) {
  const discountA = 0.1;
  return price * (1 - discountA);
}

function getPriceAfterDiscountB(price) {
  const discountB = 0.2;
  return price * (1 - discountB);
}

console.log(getPriceAfterDiscountA(100)); // 90
console.log(getPriceAfterDiscountB(100)); // 80

In this example, we have two functions with nearly identical logic, except for the discount values. This code is repetitive and not DRY.

After applying DRY:

function applyDiscount(price, discount) {
  return price * (1 - discount);
}

function getPriceAfterDiscountA(price) {
  const discountA = 0.1;
  return applyDiscount(price, discountA);
}

function getPriceAfterDiscountB(price) {
  const discountB = 0.2;
  return applyDiscount(price, discountB);
}

console.log(getPriceAfterDiscountA(100)); // 90
console.log(getPriceAfterDiscountB(100)); // 80

We've extracted the common logic into an applyDiscount() function, which is now used by both getPriceAfterDiscountA() and getPriceAfterDiscountB(). This change makes our code DRY and more maintainable.

As an of maintainability, imagine we have 10 discounts instead of the 2 above, and we have a change to this code where we want to apply some kind of pre or post-tax discount across all available discounts. Using the original method we would have to make that change in 10 places, but in the DRY code we just change the applyDiscount function. The extra layer of abstraction will result in less code, less bugs, easier to read code and more maintainable code.

Section 4: DRY Principle in JavaScript – Example 2

Let's look at another example where we want to calculate the area of different shapes:

Before applying DRY:

function calculateCircleArea(radius) {
  return Math.PI * radius * radius;
}

function calculateRectangleArea(length, width) {
  return length * width;
}

function calculateTriangleArea(base, height) {
  return (base * height) / 2;
}

After applying DRY:

function calculateArea(shape, ...dimensions) {
  switch (shape) {
    case "circle":
      const [radius] = dimensions;
      return Math.PI * radius * radius;
    case "rectangle":
      const [length, width] = dimensions;
      return length * width;
    case "triangle":
      const [base, height] = dimensions;
      return (base * height) / 2;
    default:
      throw new Error("Invalid shape");
  }
}

console.log(calculateArea("circle", 5)); // 78.53981633974483
console.log(calculateArea("rectangle", 4, 6)); // 24
console.log(calculateArea("triangle", 3, 7)); // 10.5

In this example, we've extracted the logic for calculating the area of different shapes into a single calculateArea() function. This function takes the shape and its dimensions as arguments and uses a switch statement to determine the appropriate calculation. By doing so, we've made our code DRY and easier to maintain.

Conclusion:

Embracing the DRY principle in JavaScript is an essential practice for writing clean, maintainable, and efficient code. By identifying repetitive code patterns and extracting them into reusable functions, you can reduce the likelihood of bugs and make your codebase more readable and easier to understand. Remember to always be on the lookout for opportunities to apply the DRY principle in your projects, as doing so will significantly improve the quality of your code.

Please note: This article was originally posted on Accreditly, the home of web development certifications for PHP, JavaScript, WordPress and Database Design.

Don't nest ternary operators. Please!

Accreditly — Thu, 25 Jan 2024 13:27:00 +0000

In JavaScript, the ternary operator (also known as the "conditional operator") is a concise and handy tool for conditional logic. However, when it comes to nesting these operators, you might be stepping into a tangled web of complexity. Let's discuss why nesting ternaries can be problematic and explore alternative approaches for cleaner code.

Understanding Ternary Operators

A ternary operator in JavaScript is a one-liner alternative to an if-else statement. It takes three operands: a condition, a result upon the condition being true, and a result if it's false.

Syntax:

condition ? exprIfTrue : exprIfFalse;

Example:

let isAdult = age >= 18 ? 'Yes' : 'No';

The Temptation of Nesting Ternaries

Nesting ternary operators means using one ternary inside another. It's often seen as a shortcut to handle multiple conditions.

Example of Nested Ternaries:

let category = age > 18 ? (age > 65 ? 'Senior' : 'Adult') : 'Minor';

While this might seem like an efficient use of space, it introduces several issues.

1. Readability Concerns

Nested ternaries can quickly become hard to read and understand, especially for someone new to the code. What seems straightforward to you now might be a puzzle for future-you or other developers.

Hard-to-Read Example:

let message = user.isAuthenticated ? (user.hasPremium ? 'Welcome, premium user!' : 'Welcome, user!') : 'Please log in.';

2. Debugging Difficulties

Debugging nested ternaries can be challenging. Isolating which part of the ternary chain is causing an issue is more complex than debugging a simple if-else statement or a switch case.

3. Maintainability Issues

As your codebase grows and evolves, maintaining nested ternaries becomes problematic. Any modification might require a significant unraveling and reworking of the logic.

4. Performance Misconception

Some developers might think nesting ternaries is faster or more efficient. However, any performance gains are negligible and certainly not worth the trade-off in readability and maintainability.

Alternatives to Nested Ternaries

1. Simple If-Else Statements:

For clarity and ease of understanding, a traditional if-else structure is often best.


   let category;

   if (age > 18) {
       category = age > 65 ? 'Senior' : 'Adult';
   } else {
       category = 'Minor';
   }

2. Switch Statements:

For multiple conditions, a switch statement can be more readable.


   switch (true) {
       case age > 65:
           category = 'Senior';
           break;
       case age > 18:
           category = 'Adult';
           break;
       default:
           category = 'Minor';
   }

3. Function Abstraction:

Encapsulate complex logic in a function for better abstraction and reusability.


   function getCategory(age) {
       if (age > 65) return 'Senior';
       if (age > 18) return 'Adult';
       return 'Minor';
   }

While ternary operators are a useful feature of JavaScript, nesting them can lead to code that's hard to read, debug, and maintain. Opting for clearer, more straightforward alternatives like if-else statements, switch statements, or function abstraction makes your code more accessible and maintainable. Remember, in programming, clarity should almost always trump cleverness. Production code isn't code golf, shorter isn't always better.

How to use Generators in JavaScript

Accreditly — Fri, 10 Nov 2023 11:17:52 +0000

JavaScript, a language that has been consistently evolving, introduced a powerful feature in its ES6 (ECMAScript 2015) iteration: Generators. While they might seem daunting at first, generators are invaluable tools for handling asynchronous operations and creating custom iterable sequences. Let's unwrap the mystique behind JavaScript generators.

What Are Generators?

Generators are special functions in JavaScript that allow you to yield (or produce) multiple values on a per-request basis. They pause their execution when yielding a value and can resume from where they left off. This "pausing" capability makes generators versatile for many scenarios, particularly asynchronous tasks.

Basic Syntax of Generators

Generators are defined similarly to regular functions but with an asterisk (*). The yield keyword is used to produce a sequence of values.

function* myGenerator() {
  yield 'first value';
  yield 'second value';
  yield 'third value';
}

Using a Generator

To use a generator, you must first call it, which returns a generator object:

const gen = myGenerator();

This object follows the iterator protocol and has a next() method:

console.log(gen.next()); // { value: 'first value', done: false }
console.log(gen.next()); // { value: 'second value', done: false }
console.log(gen.next()); // { value: 'third value', done: false }
console.log(gen.next()); // { value: undefined, done: true }

Benefits of Generators

Unlike traditional functions that might build and return a huge array, generators produce values on the fly. This means you're not storing large data structures in memory.
Together with Promises, generators offer a smoother way to handle asynchronous operations. This synergy gave birth to async/await, which is essentially syntactic sugar over generators and promises.
Beyond producing a sequence of values, generators can be used to define custom iteration behaviors.

Yielding Other Generators

Generators can yield other generators, making them composable:

function* generatorA() {
  yield 'A1';
  yield 'A2';
}

function* generatorB() {
  yield* generatorA();
  yield 'B1';
}

const genB = generatorB();
console.log(genB.next()); // { value: 'A1', done: false }

Generators and Error Handling

You can handle errors in generators with try-catch blocks. If an error is thrown inside a generator, it will set the done property of the generator to true.

function* errorGenerator() {
  try {
    yield 'all good';
    throw new Error('Problem occurred');
  } catch (err) {
    yield err.message;
  }
}

Real-world Use Cases

Fetching chunks of data lazily, such as paginated API results or reading large files in segments.
Generating infinite sequences, like an endless series of unique IDs.
Pausing and resuming functions, allowing for more complex flow control.

Generators offer an alternative and often cleaner approach to handling asynchronous operations and generating sequences in JavaScript. While they've been somewhat overshadowed by the rise of async/await, understanding generators gives a deeper insight into the language's capabilities. With generators in your JS toolkit, you're better equipped to tackle a wider range of programming challenges.

Example: Lazy Loading of Data

Imagine you have an application that needs to load large sets of data from a server, like a list of products in an e-commerce site. Instead of loading all data at once, which can be inefficient and slow, you can use a generator to lazily load the data as needed.

Scenario:

You have an API endpoint that returns a list of products.
The API supports pagination, allowing you to fetch a limited number of products per request.
You want to display these products in batches on the user interface, loading more as the user scrolls.

JavaScript Generator Implementation:

function* dataFetcher(apiUrl, pageSize) {
  let offset = 0;
  let hasMoreData = true;

  while (hasMoreData) {
    const url = `${apiUrl}?limit=${pageSize}&offset=${offset}`;
    yield fetch(url)
      .then(response => response.json())
      .then(data => {
        if (data.length < pageSize) {
          hasMoreData = false;
        }
        offset += data.length;
        return data;
      });
  }
}

// Using the generator
const pageSize = 10;
const apiUrl = 'https://api.example.com/products';
const loader = dataFetcher(apiUrl, pageSize);

function loadMore() {
  const nextBatch = loader.next();
  nextBatch.value.then(products => {
    // Update UI with new batch of products
  });
}

// Initial load
loadMore();

// Subsequent loads, e.g., triggered by scrolling
window.addEventListener('scroll', () => {
  // Load more data when the user scrolls down
  loadMore();
});

Example: Multi-Step Form Navigation

In a web application, you might have a multi-step form where the user needs to complete several steps in sequence. Using a generator, you can create a smooth and controlled navigation flow through these steps.

Scenario:

The application has a form divided into multiple steps (e.g., personal details, address information, payment details).
The user should be able to move forward and backward between steps.
The application should keep track of the current step and display it accordingly.

JavaScript Generator Implementation:

function* formWizard(steps) {
  let currentStep = 0;

  while (true) {
    const action = yield steps[currentStep];

    if (action === 'next' && currentStep < steps.length - 1) {
      currentStep++;
    } else if (action === 'prev' && currentStep > 0) {
      currentStep--;
    }
  }
}

// Define the steps of the form
const steps = ['Step 1: Personal Details', 'Step 2: Address Information', 'Step 3: Payment Details'];

// Create an instance of the form wizard
const wizard = formWizard(steps);

// Function to move to the next step
function nextStep() {
  wizard.next('next').value.then(currentStep => {
    // Update UI to show the current step
  });
}

// Function to move to the previous step
function prevStep() {
  wizard.next('prev').value.then(currentStep => {
    // Update UI to show the current step
  });
}

// Initial step
nextStep();

DOM traversal in JavaScript

Accreditly — Mon, 21 Aug 2023 13:39:03 +0000

Introduction

The Document Object Model (DOM) represents the structure of an HTML document. Navigating or "traversing" this structure is a fundamental aspect of web development, enabling developers to select, modify, delete, or add content on a webpage. This comprehensive guide delves deep into the art of DOM traversal using JavaScript, equipping you with a robust toolkit for handling various traversal scenarios.

We've done a more comprehensive version of this article over on Accreditly's website: A guide to DOM traversal in JavaScript.

An remember, if you're interested in showcasing your JavaScript skills then be sure to check out our JavaScript Fundamentals certification.

1. Basic DOM Selectors

Before we jump into traversal, let's review some fundamental DOM selectors.

getElementById(): Returns a reference to the first element with the specified ID.

const header = document.getElementById('header');

getElementsByClassName(): Returns a live HTMLCollection of elements with the given class name.

const buttons = document.getElementsByClassName('btn');

getElementsByTagName(): Returns a live HTMLCollection of elements with the given tag name.

const paragraphs = document.getElementsByTagName('p');

querySelector(): Returns the first element that matches a specified CSS selector.

const mainImage = document.querySelector('.main-image');

querySelectorAll(): Returns a static NodeList representing elements that match a specified CSS selector.

const listItems = document.querySelectorAll('ul li');

2. Parent, Child, and Sibling Relationships

At the core of DOM traversal are the relationships between nodes.

2.1. Parent Nodes

parentNode: Returns the parent node of a specified element.

const parentOfButton = document.querySelector('.btn').parentNode;

2.2. Child Nodes

firstChild & lastChild: Return the first and last child of a node, respectively.

const firstChildOfDiv = document.querySelector('div').firstChild;
const lastChildOfDiv = document.querySelector('div').lastChild;

children: Returns an HTMLCollection of an element's child elements (excludes text and comment nodes).

const divChildren = document.querySelector('div').children;

firstElementChild & lastElementChild: Similar to firstChild and lastChild, but strictly return element nodes.

const firstElementChildOfDiv = document.querySelector('div').firstElementChild;

2.3. Sibling Nodes

nextSibling & previousSibling: Return the next and previous sibling of an element, respectively.

const nextToButton = document.querySelector('.btn').nextSibling;
const prevToButton = document.querySelector('.btn').previousSibling;

nextElementSibling & previousElementSibling: Similar to nextSibling and previousSibling, but strictly for element nodes.

const nextElementToButton = document.querySelector('.btn').nextElementSibling;

3. Traversal Methods

3.1. Node Iteration

childNodes: Returns a NodeList of child nodes.

const listNodes = document.querySelector('ul').childNodes;

3.2. Filtering Elements

Utilize Array.prototype.filter to filter nodes based on conditions.

const listItems = document.querySelector('ul').children;
const redItems = [...listItems].filter(item => item.style.color === 'red');

4. DOM Traversal with Events

Combine event listeners with traversal methods to create interactive elements.

document.querySelector('.btn').addEventListener('click', function(e) {
  const nextElement = e.target.nextElementSibling;
  if (nextElement) {
    nextElement.style.display = 'none';
  }
});

5. Advanced Traversal Techniques

5.1. Recursive Traversal

Traverse the entire DOM tree recursively. This method is useful when the depth is unknown:

function traverseDOM(node) {
  console.log(node);
  const children = node.children;
  for (let child of children) {
    traverseDOM(child);
  }
}

traverseDOM(document.body);

5.2. Climbing Up the DOM

In some cases, you may need to find a parent element with a specific selector:

function findAncestor(el, selector) {
  while ((el = el.parentElement) && !el.matches(selector));
  return el;
}

const listItem = document.querySelector('li');
const containingDiv = findAncestor(listItem, 'div');

Mastering DOM traversal is paramount for any full-stack or frontend developer. JavaScript provides a plethora of methods and properties to navigate the intricate relationships of the DOM.

Streaming Large Files with PHP to Save Memory

Accreditly — Sat, 12 Aug 2023 13:24:52 +0000

Handling large files is a common task for web developers. However, if not done properly, it can lead to high memory usage and slow performance. In this tutorial, we will look at how to stream large files to the browser in a memory-efficient way using PHP.

Prerequisites

Basic knowledge of PHP
An active PHP development environment

Step 1: File Streaming Basics

Before we dive into the code, let's first understand what file streaming is. When you open a file in PHP with fopen(), you can read it line by line or character by character with fgets() or fgetc(), instead of loading the entire file into memory. This is known as file streaming.

Step 2: Setting Up the PHP Script

Let's create a new PHP script, download.php. In this script, we will:

Open the file we want to stream.
Read a portion of the file and output it to the browser.
Repeat step 2 until the entire file has been read and sent.

Here's the code:

<?php
$file = 'path/to/your/largefile.pdf';

// Make sure the file exists
if (!file_exists($file)) {
    die('File not found.');
}

// Set headers to tell the browser to download the file
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="'.basename($file).'"');
header('Content-Length: ' . filesize($file));

// Open the file in binary mode
$fp = fopen($file, 'rb');

// Output the file
while (!feof($fp)) {
    // Read and output a chunk of the file
    echo fread($fp, 8192);

    // Flush the output buffer to free up memory
    ob_flush();
    flush();
}

// Close the file
fclose($fp);
exit;

In the above code, we use fopen() to open the file and fread() to read a chunk of 8192 bytes at a time (which is approximately 8KB). We then output this chunk using echo and flush the output buffer to free up the memory used. This process repeats until the end of the file (feof($fp) returns true).

In this tutorial, you've learned how to stream large files to the browser in a memory-efficient way using PHP. This method is very useful when dealing with large files that could otherwise consume significant server memory and lead to performance issues. Always remember to close any open file handles and flush the output buffer to free up memory.

Building a frontend auth in WordPress

Accreditly — Tue, 01 Aug 2023 10:06:02 +0000

WordPress, love it or hate it, is here to stay. It powers ~65% of the Internet, and is used by corporations large and small, bloggers, agencies and everything in between.

As WordPress website's grow in functionality it often becomes necessary for users to log into the site. One example of this may be when you offer (pay)walled content, whereby a user must be logged in to read it.

There are plugins that can do this, but that's a heavy dependency on a third-party that can introduce security risks, not to mention a risk of them disappearing (this happens more often than you may think, even for popular plugins).

So, roll your own.

We've created a series of tutorials on how to build your own frontend auth experience in WordPress.

This series of articles takes you through the following:

Check it out, and if you have any questions let us know in the comments.

Understanding blobs in JavaScript

Accreditly — Fri, 21 Jul 2023 08:57:19 +0000

JavaScript, a powerful and flexible language, offers many features that make it a staple for client-side web development. One of these features is the Blob object, a fundamental data type that plays a crucial role when dealing with binary data.

What is a Blob?

A Blob (Binary Large OBject) is an immutable object in JavaScript that represents raw, unprocessed data. This data can be of any type and is not limited to binary. Blobs are typically used to store data such as images, audio, or other multimedia files, though they can hold almost any data type.

The data contained in a Blob is not necessarily in a JavaScript-native format. The File interface is based on Blob, inheriting blob functionality and expanding it to provide features like name and lastModified.

Creating a Blob

You can create a Blob object in JavaScript using the Blob constructor. Here's a simple example:

let helloBlob = new Blob(["Hello, Blob!"], {type : "text/plain"});

In the example above, the Blob constructor takes two arguments:

An array of data parts: This could be a simple array of strings, ArrayBuffer, ArrayBufferView (a typed array), Blob objects, or a mix of any of the above.
An options object: This is optional and can be used to specify the MIME type of the data.

Reading a Blob

let reader = new FileReader();
reader.onload = function() {
  console.log(reader.result);
}
let blob = new Blob(["Hello, Blob!"], {type : "text/plain"});
reader.readAsText(blob);

In this example, the readAsText method is used to read the content of the blob as a string.

Blob URLs

Blobs can also be used to create URLs that can be used to link or display binary data such as an image. This is done using the URL.createObjectURL() method.

Here's an example:

let blob = new Blob(["Hello, Blob!"], {type : "text/plain"});
let blobUrl = URL.createObjectURL(blob);

// Now you can use blobUrl to display the data
console.log(blobUrl); // Outputs something like: blob:http://your-url.com/550e8400-e29b-41d4-a716-446655440000

The URL.createObjectURL() method creates a DOMString containing an URL representing the object given in the parameter.

In summary, the Blob object is a powerful tool in JavaScript for handling raw data. It is particularly useful for working with binary objects where you need to manipulate files, such as images or multimedia content. Understanding how to use Blobs effectively can greatly expand your JavaScript capabilities when handling complex data types.

You can read more about Blobs, and their Web API on the MDN docs.

Read this article on Accreditly.

How to migrate a live website without losing data

Accreditly — Thu, 20 Jul 2023 09:52:48 +0000

In this guide we're going to discuss how to migrate a live website to a new infrastructure with no downtime and without losing data.

Website being migrated

We'll assume in this example that we're dealing with a busy ecommerce website. The ecommerce website processes around 500 orders a day, so downtime is costly, and data is constantly moving.

Problem areas of a migration

It's important to understand the potential issues with any migration. These include:

Data in your database (the most challenging aspect)
Your code and changes
Environment files and variables not in version control
Files uploaded in your application
DNS changes

Current architecture

Let's start by outlying our current infrastructure. We'll try and keep it simple. If you have more complex infrastructure then it's likely this guide will still work, or you'll understand the nuances enough to translate it to your own use case.

Our current infrastructure consists of a single app server, which contains our web server (Apache or nginx) and a database server (MySQL). This guide will work perfectly fine if you're on immutable architecture (eg. multiple web servers, load balancer and single database).

User uploaded files

Files uploaded by users are currently handled by S3, so there isn't much for us to worry about there as that will continue to happen. On any solution I always recommend using an external service for housing user uploaded files as it is cheaper, more reliable, easier to implement, easier to migrate, and you won't be plagued with disk space issues.

However, we'll discuss how you can migrate files as part of this guide.

The migration

OK, let's begin.

User uploaded files

In our app we use S3 for files, so really this doesn't need much attention at all, but if you're not using a third party to handled user uploaded files then you'll need to move them there.

Unfortunately, although this process is reasonably straightforward, it will require changes to your application code. There are ways to do it without changing code (such as rsyncing to the service), but they aren't recommended.

1. Make changes to your codebase to use the service's endpoint for files.

With this we'll assume we're using AWS S3. You'll need to make changes to your app's code to point at S3 rather than your local files. Obviously the steps to do this vary depending on your own application. I'd also recommend putting Cloudfront in front of your S3 bucket for both speed and cost savings.

You should put this change behind a feature flag. A feature flag is a concept used in software development to enable and disable features of an app very quickly. In simple terms it's a config file full of booleans. In our case it allows us to quickly switch from using local files to S3 files by changing a single variable.

Once it's all implemented and tested, leave the feature turned off so we're still serving local files.

2. Move existing files to S3.

Next we need to move all of our existing files to S3. The easiest way to do this is using AWS' CLI client.

First off set up an IAM user who has read-write access to a bucket on S3.

Then install AWS CLI on your server.

Then you can sync all of your files:

aws s3 sync source_folder  s3://your_bucket_name/destination_folder/

Please note: You don't have to use AWS S3. There are now lots of other services available, which are often cheaper than S3, that use the same suite of APIs as S3 so they're drop-in replacements.

3. (Optional) set up Cloudfront

Cloudfront is a CDN. It has many uses, but for us it sits in front of S3 and serves files for us.

You can configure Cloudfront to run as 'origin pull', where it will pull files with the same path requested directly from S3, and then cache them indefinitely.

For example, let's say you have a file:

https://example-s3-bucket.com/images/myfile.jpg

Once configured you can instead request:

https://my-example-app.cloudfront.net/images/myfile.jpg

On the first request Cloudfront will download the file to the CDN, cache it, then serve it to the user. Subsequent requests will serve the cached file.

AWS have a guide on setting this up.

4. Ensure future files are uploaded to S3

You'll need to change your application's code to ensure future files are uploaded to S3.

You have multiple options here, you can opt to upload files directly to AWS S3 from a HTML form, or you can upload them to your server and sync from there.

There is no right or wrong approach, it depends on your circumstances.

Ensure this feature also has its own feature flag, or ties into the original feature flag from step 1.

5. Go live with S3 files

Once tested and you're happy you can resync all of your files (step 2: aws s3 sync source_folder s3://your_bucket_name/destination_folder/), and then go live.

Going live is as simple as changing the feature flag to true.

You can always re-sync after going live, just in case any files were uploaded during the last sync prior to going live.

You can get this done prior to the rest of the migration.

DNS preparation

OK, so that's user files taken care of, now we need to prep DNS.

DNS is a subject that is simple for the basics, but extremely complex when you dig into it. Fortunately we're sticking to the basics.

DNS is just a list of signposts for services. When someone's browser requests example.com their computer will ask the nameserver (DNS server) for that domain what IP address example.com points to. It's as simple as that.

A DNS record consists of:

Record type (A, AAAA, CNAME, TXT, MX, etc)
Record target (example.com, www.example.com, whatever.example.com)
Record value (IP address for a lot of records, a string for others)
TTL (time to live. Effectively the amount of time to cache the record)

During the migration we're going to change the record value for both our root domain (example.com) and www. record.

In preparation for this we need to do 2 things:

1. Ensure `www.` is a CNAME for the root domain

Assuming this works for your infrastructure, you should ensure the www. record of your domain DNS is a CNAME that points back to the root domain:

CNAME www.example.com example.com

This is generally considered best practice, simply because you only need to change one record to move the domain which reduces chances of human error, or extremely rare issues like your DNS provider having an outage half way through editing 2 fields.

Doing this ahead of time gives your DNS time to propagate to providers.

2. Reduce your TTL

The TTL of your records is effectively the time DNS providers cache the record.

During normal activities you are safe to set this as a reasonably high value such as an hour, or a day (in seconds). However, during a migration we want DNS providers to update as fast as possible, so it's a good idea to update this to a much lower value.

Most DNS providers have a lower cap on what they'll allow, but you should be able to set it to something like 30, which is 30 seconds.

Doing this ahead of time allows DNS providers to update their systems accordingly.

Remember though, TTL is a guidance you provide and it's up to DNS providers to actually take note of it. Many ISPs, especially residential ISPs who provide DNS services to their customers, will heavily cache records regardless of your TTL.

Set up your new infrastructure and code freeze

At this point you'll want to set up your new infrastructure and ensure everything works as expected.

You can test it using a hosts file entry. Getting this all set up is outside the scope of this guide.

Once set up you should have the following in place:

Old infrastructure still in place.
Files on old infrastructure being uploaded to a third-party such as S3.
DNS prepared for fast changes.
New infrastructure in place, but not used yet.

At this point you need to implement a code freeze. No more code changes can be made, and no deployments should be made.

Migrate and sync data

The most challenging part of moving a live website that transacts is the database. The data is changing with every transaction, and your application is probably writing to the database frequently.

There are a number of solutions to moving your data without causing any data loss. We'll be focusing on two solutions here (there are others).

1. Migrate and remote connect

The first and simplest option is to use a remote connection. Read on for how this works, but be aware that you could be unlucky and have a small amount of "data loss" (it is recoverable) with this approach, so it's important you understand the risk involved.

OK, so this approach involves setting up your new infrastructure to allow remote connections. You then manually migrate your data from old infrastructure (create an export, transfer it to new server, import it). Once migrated you change the connection details on the old infrastructure to point to the database on the new infrastructure.

At this point your visitors will be using the web server on the old infrastructure, but the database server on the new infrastructure. This allows you to then make DNS changes and it doesn't really matter how long it takes to propagate.

There are risks. Running an export, transferring it, and importing again takes time. How much time depends on the amount of data and the resources available on all machines involved. If you don't have a particularly busy website then this is probably OK.

If the worst should happen and your website makes a sale during the migration then the data isn't lost, it will be sat on the old database. Depending on the complexity of your data schema it might be straightforward to manually move the missing rows to your new database.

2. Create a master/slave setup

MySQL has a concept called master/slave, something that was popular with older hard drives that were prone to failure.

Effectively the master database acts as you would expect it to, all writes go into it, and any data being read by the application is read from there.

The slave is never read from, but any writes that happen also happen to the slave. You effectively get a real-time copy of the database that is constantly being updated as changes happen.

The concept here is to set up the database on the old infrastructure as the master, and set up the database on the new infrastructure as the slave. Once you're happy data is being written to both you can simply switch roles so the new infrastructure becomes the master.

This approach seems much simpler, and won't incur any data loss. However, setting up remote master/slave instances isn't as straightforward as it may seem and it adds a level of complication that may not be favourable.

Although this solution is housed entirely in MySQL it is possible to do it within the application itself. Many application frameworks support master/slave setups, where you're able to set up a single 'read' source with multiple write destinations (or multiple reads to load balance your databases). You may find it easier to implement the master/slave setup in your application rather than in MySQL.

DigitalOcean have a great guide on MySQL replication.

Environment files & tertiary setup

By this point you should have tested your application on the new infrastructure many times, so it should be obvious whether anything isn't working. However, a few gotchas that can come up when moving between infrastructure to check at this point:

Ensure you have all environment variables set up on new infrastructure (.env file or equivalent).
Ensure you have a migration process in place for deployments. This differs massively depending on your setup, but make sure when you make the change you aren't deploying code changes to old infrastructure.
Ensure your scheduler or equivalent is setup and running on your new infrastructure.
Ensure any queue runners and daemons are setup and running on your new infrastructure.

Go live

So at this point you should have:

Identical code on old and new infrastructure
User uploaded files on a third party like S3
Database is now on new infrastructure
Code is still being run on old infrastructure
DNS is prepared with low TTL and CNAME on www.
Tested new infrastructure thoroughly

All that is left to do is to change your DNS record on the root domain to point to the new infrastructure. You should start to see traffic within a minute or two, and within 24 hours (remember, not all DNS providers follow your TTL) all traffic should be hitting the new infrastructure.

The benefits of this piecemeal approach to the migration is that if you encounter an issue at any point, you can easily roll it back. So after moving DNS, if the new infrastructure catches fire, you can just switch the DNS back and you shouldn't encounter any data loss.

Summary

OK so let's go through what we did there from a high level.

Ensured we're using immutable user-uploaded files. If not, migrate to S3 or similar.
Prepped DNS.
Migrated data.
Began using database on new infrastructure, with a failover back to old infrastructure.
Switched DNS to new infrastructure.

At any point in this whole process we have a live backup of the previous setup to revert to. For example, if you switch the database to new infrastructure and it fails, you can switch to old without any data loss (especially if you use master/slave), or if you switch DNS and something fails you can easily switch back with no data loss or downtime.

An exact migration plan will differ depending on your application's specifics though. More complex applications may also have additional requirements that need handling, such as:

Key-value storage for sessions or caching. If you have this then you'll need to understand how you're going to invalidate sessions upon moving infrastructure. You don't want to destroy people's cart sessions as they're about to transact.
Queue and job processing. Many applications offload tasks to a queue to be processed. There are many solutions for handling this, but if you're handling it all within your own infrastructure then you'll need to ensure this is also moved without any interruption. There are many options here, but most applications support multiple queues, so it should be trivial to pause the queue processing, migrate to new infrastructure, and then process it there.
Webhooks. Webhooks shouldn't be affected by the migration, because both infrastructure should be able to handle inbound web requests within the same database environment at all times. But if the worst happens and you encounter any issues that result in downtime you will need to have a recovery process in place to handle missed webhooks. Most services will retry failed webhooks after a period of time, and will offer a way to manually fire them at a later point should you need to, just remember to check them.
Other services. There's no one-size-fits-all migration plan. You know your application, if there's something not considered here then you'll need to ensure it's handled properly.

Hopefully this is of use to you. If you have any questions or suggestions, feel free to leave a comment.

The double not operator (!!)

Accreditly — Wed, 21 Jun 2023 16:51:05 +0000

In the realm of programming, operators are tools that allow us to perform operations on variables and values. One such operator that often catches developers off-guard is the double not operator (!!). This article delves into what the double not operator is, when and why to use it, and when to avoid it. We'll also explore examples in both PHP and JavaScript, two languages where this operator can be handy.

What is the Double Not Operator?

In both PHP and JavaScript (and many other languages), the ! symbol is a logical NOT operator. It negates the truthiness of the operand that follows it. If the value is truthy (i.e., evaluates to true in a boolean context), ! turns it to false and vice versa.

We've covered what it is in PHP extensively in our article The double not (!!) operator.

The double not operator (!!) is simply the ! operator used twice. The first ! converts the operand to its boolean opposite, and the second ! flips it back. The result is a value that is explicitly either true or false.

Let's look at an example in JavaScript:

let truthyValue = 'Hello, world!';
console.log(!!truthyValue); // Outputs: true

let falsyValue = '';
console.log(!!falsyValue); // Outputs: false

And the same in PHP:

$truthyValue = 'Hello, world!';
var_dump(!!$truthyValue); // Outputs: bool(true)

$falsyValue = '';
var_dump(!!$falsyValue); // Outputs: bool(false)

Why and When to Use the Double Not Operator

The double not operator is a quick and concise way to convert any value to its boolean equivalent. It's particularly useful in conditions where you need to ensure a variable's truthy or falsy nature and not its actual value.

In JavaScript, it can be beneficial due to the language's loose typing and because various values can be considered "falsy" (e.g., null, undefined, 0, NaN, empty string, etc.). Using !! can help normalize these values to a proper boolean.

Here's an example where !! can be used effectively in JavaScript:

let user = {
    name: 'John Doe',
    // isAdmin property is missing
};

if (!!user.isAdmin) {
    console.log('User is an admin');
} else {
    console.log('User is not an admin');
}

In this case, because isAdmin is missing, !!user.isAdmin will return false, and 'User is not an admin' will be printed.

In PHP, the !! operator can also be useful in conditional checks, especially when dealing with values that could be considered "falsy" like 0, null, false, empty string, etc.

$isAdmin = 0;

if (!!$isAdmin) {
    echo 'User is an admin';
} else {
    echo 'User is not an admin';
}

When to Avoid the Double Not Operator

While !! can be handy, it can also make code more difficult to read, especially for those unfamiliar with this operator. It's not as explicit as using methods like Boolean() in JavaScript or (bool) casting in PHP, which achieve the same result.

Here are equivalent examples without !!:

JavaScript:

let truthyValue = 'Hello, world!';
console.log(Boolean(truthyValue)); // Outputs: true

PHP:

$truthyValue = 'Hello, world!';
var_dump((bool)$truthyValue); // Outputs: bool(true)

If readability and clarity are a priority, or if you're working with developers who may not be familiar with !!, it may be best to use these more explicit methods to convert values to their boolean equivalent.

The double not operator (!!) is a quick, if somewhat cryptic, way to convert any value to a boolean in languages like JavaScript and PHP. While it's a clever trick and can come in handy, remember that it may come at the cost of readability. Use your judgment and consider your team's familiarity with such nuances when deciding whether to use it in your code.

If you're an experienced developer and have come across the double not operator before then you may be interested in both our PHP Fundamentals Certification and JavaScript Fundamentals Certification.

DEV Community: Accreditly

How to use Tailwinds `safelist` to handle dynamic classes

1. Understanding PurgeCSS in Tailwind CSS

2. Introducing Safelist

3. Configuring Safelist in tailwind.config.js

4. More advanced configurations

5. Safelist Examples and Use Cases

6. Best Practices for Safelisting

Summary

Send email from WordPress the right way

Why Avoid PHP’s mail() Function?

Sending Plaintext Emails with WordPress

Crafting HTML Emails in WordPress

Enhance Your WordPress Skills

The Differences Between "Test Coverage" and "Code Coverage"

Understanding Test Coverage

Why Test Coverage Matters

Measuring Test Coverage

Understanding Code Coverage

Why Code Coverage Matters

Measuring Code Coverage

Key Differences Between Test Coverage and Code Coverage

Focus

Measurement

Purpose

Using Test Coverage and Code Coverage Together

Showing Off Coverage

Example Workflow

Further Reading

DRY: What is it and how to implement it. Don't Repeat Yourself

Section 1: Understanding the DRY Principle

Section 2: Benefits of the DRY Principle

Section 3: DRY Principle in JavaScript – Example 1

Section 4: DRY Principle in JavaScript – Example 2

Conclusion:

Don't nest ternary operators. Please!

Understanding Ternary Operators

The Temptation of Nesting Ternaries

1. Readability Concerns

2. Debugging Difficulties

3. Maintainability Issues

4. Performance Misconception

Alternatives to Nested Ternaries

How to use Generators in JavaScript

What Are Generators?

Basic Syntax of Generators

Using a Generator

Benefits of Generators

Yielding Other Generators

Generators and Error Handling

Real-world Use Cases

Example: Lazy Loading of Data

Example: Multi-Step Form Navigation

DOM traversal in JavaScript

Introduction

1. Basic DOM Selectors

2. Parent, Child, and Sibling Relationships

2.1. Parent Nodes

2.2. Child Nodes

2.3. Sibling Nodes

3. Traversal Methods

3.1. Node Iteration

3.2. Filtering Elements

4. DOM Traversal with Events

5. Advanced Traversal Techniques

5.1. Recursive Traversal

5.2. Climbing Up the DOM

Streaming Large Files with PHP to Save Memory

Prerequisites

Step 1: File Streaming Basics

Step 2: Setting Up the PHP Script

Building a frontend auth in WordPress

Understanding blobs in JavaScript

What is a Blob?

Creating a Blob

Reading a Blob

Blob URLs

How to migrate a live website without losing data

Website being migrated

Problem areas of a migration

3. Configuring Safelist in `tailwind.config.js`

Why Avoid PHP’s `mail()` Function?

1. Ensure `www.` is a CNAME for the root domain