DEV Community: Leonardo Theodoro

Avoiding Catastrophic Backtracking in Regular Expressions

Leonardo Theodoro — Fri, 21 Feb 2025 12:27:07 +0000

Hey everyone! Today, I want to talk about a problem that can turn your regular expressions into real ticking time bombs for your application's performance: Catastrophic Backtracking. You might have encountered this without even realizing it, especially if your regex handles complex searches or unexpectedly locks up.

So, if you want to avoid freezes, infinite loops, and major headaches when working with regex, this article is for you. Let’s break down this issue and how to prevent it!

What is Catastrophic Backtracking?

Backtracking is a mechanism that most regex engines use to find matches. Basically, when a regex fails to match a pattern, the engine backtracks a few steps and tries another approach.

The problem arises when the regex is structured in a way that creates too many possible matching combinations before finally failing. This causes the regex engine to go through an exponential number of attempts before giving up, potentially freezing your application.

How does the problem occur in practice?

Let's understand this issue with a practical example. Imagine you want to validate a string that contains only the letter "a" followed by the letter "b," and you write the following expression:

^(a+)+b$

Now, let's test it with a string that should fail:

const regex = /^(a+)+b$/;

console.log(regex.test("aaab")); // true (valid)
console.log(regex.test("aaaaaaaaaaaaaaaaaaaaa")); // Fails, but not immediately!

The first test works correctly, but the second one can cause the regex engine to freeze. This happens because the pattern (a+)+ allows multiple ways to group the "a" characters, and the engine attempts all these combinations before realizing the string doesn’t contain a "b" at the end.

Let’s visualize what the engine is doing:

It starts by trying to group all the "a" characters inside the first (a+).
Since there’s another (a+) wrapping this group, it attempts to redistribute the "a" characters in multiple ways.
When it reaches the end of the string and doesn't find "b," it backtracks and tries different ways to group the "a" characters.
Since there are so many ways to distribute the "a" characters, the number of attempts grows exponentially, causing the engine to freeze.

This behavior is called Catastrophic Backtracking because the execution time grows unpredictably depending on the input size.

How to Avoid Catastrophic Backtracking?

Now that you understand the problem, let’s go over some solutions to prevent it:

1. Avoid Unnecessary Groups

If you don’t need to capture something, remove the parentheses. In the previous example, ^(a+)+b$ can be simplified to:

^a+b$

2. Use Boundary Anchors

Whenever possible, use ^ and $ to mark the start and end of the string, preventing unnecessary backtracking attempts.

3. **Use Lazy Quantifiers (*?, +?, ??)

If you need to use repetitive quantifiers, try using the lazy version to reduce the number of attempts. For example:

^a+?b$

4. Use Atomic Groups (`(?>...)`)

If you're dealing with repetitive groups, you can tell the engine not to backtrack inside the group using (?>...).

^(?>a+)+b$

Conclusion

If you've ever had regex slow down or crash your application, now you know that Catastrophic Backtracking might be the culprit. Avoiding this problem is just a matter of applying best practices.

See you next time!

What Are Async Generators and What Are They Used For?

Leonardo Theodoro — Wed, 19 Feb 2025 13:01:50 +0000

As a developer, you've probably dealt with data streams that aren’t immediately available – think about data coming from an API, chunked downloads, or even reading large files. In these scenarios, it’s crucial to have an elegant and efficient approach to processing data as it arrives. This is where async iterators come in. But before diving into this concept, let’s first understand how synchronous iterators work.

What Are Iterators?

An iterator is an object that defines a sequence and knows how to access its elements one at a time through a method called next(). In JavaScript, to make an object iterable – meaning it can be traversed using a for..of loop – we define a special method called Symbol.iterator.

Imagine we have a range object that represents a range of numbers:

const range = {
    from: 1,
    to: 5,

    [Symbol.iterator]() {
        return {
            current: this.from,
            last: this.to,
            next() {
                if (this.current <= this.last) {
                    return { done: false, value: this.current++ };
                } else {
                    return { done: true };
                }
            }
        };
    }
};

for (let value of range) {
    console.log(value); // Prints: 1, 2, 3, 4, 5
}

In this example, each call to next() returns an object with the structure { value, done }. As long as done is false, the loop continues, allowing for..of to iterate over all values in the range.

Limitations of Iterators

While synchronous iterators work well for sequences of immediately available data, they fail when values are only known or available asynchronously – for instance, when each value depends on a network request or a delay (setTimeout).

Imagine you need to iterate over a sequence that depends on an operation that takes time to complete (such as an API call). Using a synchronous iterator won’t work in this case because the next() method cannot wait for a Promise to resolve or a delay to pass.

Generators: Simplifying Iterator Creation

Manually implementing an iterator can be verbose. Generators simplify this process. They are special functions that can "pause" execution using the yield keyword, returning values on demand and maintaining internal state between calls.

A generator is defined using function* and can be used to create iterators concisely:

function* generateSequence(start, end) {
    for (let i = start; i <= end; i++) {
        yield i;
    }
}

for (let value of generateSequence(1, 5)) {
    console.log(value); // Prints: 1, 2, 3, 4, 5
}

Introducing Async Iterators

Async iterators were created specifically to handle scenarios where values are obtained asynchronously. They work similarly to synchronous iterators but with some key differences:

Iteration method: Instead of implementing Symbol.iterator, we use Symbol.asyncIterator.
**next()**** method:** In an async iterator, next() returns a Promise that resolves to an object { value, done }.
Iteration loop: To consume values, we use for await...of, which waits for each Promise to resolve before proceeding.

Let’s refactor the range example so that values are returned with a 1-second delay:

const asyncRange = {
    from: 1,
    to: 5,

    [Symbol.asyncIterator]() {
        return {
            current: this.from,
            last: this.to,
            async next() {
                // Simulating a delay (as if waiting for a network response)
                await new Promise(resolve => setTimeout(resolve, 1000));

                if (this.current <= this.last) {
                    return { done: false, value: this.current++ };
                } else {
                    return { done: true };
                }
            }
        };
    }
};

(async () => {
    for await (let value of asyncRange) {
        console.log(value); // Prints: 1, 2, 3, 4, 5 (with a 1-second interval)
    }
})();

In this code, each iteration waits for the delay to resolve before proceeding, allowing data to be processed as it arrives.

Why Use Async Iterators?

Now that we understand the difference between synchronous iterators and async iterators, let’s explore the advantages of using async iterators in everyday coding:

1. On-Demand Processing

In many cases, data arrives in fragments. Instead of waiting for all data to be available, an async iterator allows processing each value as soon as it arrives. This is especially useful for:

Paginated requests: Processing API results page by page instead of loading everything at once.
Data streams: Such as downloading or uploading files where data is received in chunks.

2. Integration with Asynchronous APIs

Many modern APIs (such as Fetch API or Streams API) handle data asynchronously. Async iterators allow integrating these data flows naturally and consistently, avoiding "hacks" or excessive code coupling.

3. Performance and Efficiency Improvements

By processing data on demand, we avoid loading large volumes of data into memory all at once. This can lead to significant performance improvements, especially when dealing with large data streams.

Practical Example: Paginating Data with Async Iterators

A classic example of using async iterators is paginating data. Suppose we need to fetch commits from a GitHub repository, where each request returns a page with 30 commits and provides a link to the next page.

Using an async iterator, we can create a fetchCommits(repo) function that handles all pagination logic and allows us to iterate over the commits seamlessly:

async function* fetchCommits(repo) {
    let url = `https://api.github.com/repos/${repo}/commits`;

    while (url) {
        const response = await fetch(url, {
            headers: { 'User-Agent': 'Our App' }
        });
        const commits = await response.json();

        // Extracts the link to the next page, if available
        let nextPageMatch = response.headers.get('Link')?.match(/<([^>]+)>;\s*rel="next"/);
        url = nextPageMatch ? nextPageMatch[1] : null;

        for (let commit of commits) {
            yield commit;
        }
    }
}

(async () => {
    for await (let commit of fetchCommits("username/repository")) {
        // Process each commit as it arrives
        console.log(commit);
    }
})();

This pattern allows you to process commits continuously and efficiently, without worrying about pagination logic in each call.

Final Considerations

Async iterators are a powerful tool for working with asynchronously arriving data. By allowing on-demand iteration, they simplify integration with modern APIs, make code cleaner and more expressive, and help avoid performance issues when handling large data streams.

In summary, opting for async iterators provides:

Control: Processing data as it becomes available.
Readability: Using for await...of for more intuitive code.
Efficiency: Avoiding unnecessary large memory loads.
Integration: Easy handling of asynchronous APIs and real-time data streams.

See you next time!

Where do our variables go - A brief guide to Call Stack and Memory Heap

Leonardo Theodoro — Wed, 19 Feb 2025 11:23:15 +0000

Have you written countless JavaScript codes and developed various systems, but have you ever stopped to wonder how some things work behind the scenes?

Today, I want to introduce you to two terms that I didn't know before and found interesting to learn about: Call Stack and Memory Heap.

JavaScript Memory Model

First, we need to understand what happens when we declare a variable and initialize it. In the example below, I declared the variable x with the value of 1 and created another variable equivalent to x, then changed the value of x.

let x = 1
let y = x

x = x + 1;

console.log(y) // Result?

What do you think will happen when we print y?

If you think the value of y will be 2, you're wrong—but let me explain why.

When x was created, JavaScript generated a unique identifier and allocated it to a memory address (e.g., M001) while also storing the variable's value at that memory address.
When I said let y = x, I meant that y is equivalent to the memory address M001 and not equal to the value of x.
When I changed the value of x, JavaScript allocated a new memory address and saved the value 2 at address M002. This happens because primitive data types (string, number, boolean, undefined, and symbol) are immutable.

What is the Role of the Call Stack?

The Call Stack works like a stack (FILO - First In, Last Out). It organizes function calls, adding and removing them after the code is executed. Additionally, it is responsible for storing primitive types.

It’s also in the Call Stack that a phenomenon you’ve probably heard of occurs: Stack Overflow. This happens when functions are stacked indefinitely, and the stack exceeds the maximum memory limit.

Here’s a quick example of how we can cause a stack overflow using recursion:

function recursion() {
    recursion();
}

recursion();

So, what does the Memory Heap do?

Unlike the Call Stack, the Memory Heap is where non-primitive data (arrays, objects, and functions) is stored. It allows data to grow dynamically and be organized in a non-sequential manner.

Here’s how the Memory Heap works. Check out this example:

const arr = [];
arr.push(1);

In this case, when we declare the variable arr, the Call Stack saves a reference value pointing to the Memory Heap, where the actual values are managed. In this case, the push modifies the Heap's content but not the reference address in the Call Stack.

`const` and Non-Primitive Data

When we declare a variable with const, we cannot reassign its value. However, for arrays and objects, it’s possible to modify the items internally. This happens because the identifier in the Call Stack remains the same, while the values are managed in the Heap.

In summary, when we perform a push on an array, it doesn’t change the memory address—it changes the value in the Heap. The same applies to objects.

Here’s a reference table to make this clearer:

Variable	Call Stack		Heap
	Address	Value	Address	Value
x	CS001	2
y	CS002	1
arr	CS003 (points to H001)		H001 (points to ->)	[]

Can Primitive Types Ever "Go" to the Heap?

Yes, there are cases where primitive types can "go" to the Heap, and this happens indirectly when you use a wrapper.

For example, if I declare a variable as new String("Text") instead of a plain string, the value is treated as an object and stored in the Heap.

Garbage Collection and Memory Leaks

JavaScript has automatic memory management, meaning it cleans up unreferenced addresses (i.e., those no longer in use) automatically. This process is called "garbage collection" and uses the Mark and Sweep algorithm, which identifies and removes inaccessible variables.

However, Memory Leaks (when available memory is exceeded) can still occur. Here are the most common causes of Memory Leaks:

Global Variables
Global variables are difficult to collect because they are always accessible:

const x = 1
const y = 2;
const z = 3

Event Listeners
Event listeners that are not removed can remain active, causing leaks:

const button = document.getElementById('myButton'); 

// Add an event listener to the button
button.addEventListener('click', () => { console.log('Button clicked!'); }); 

// Problem: the listener will not be removed even if the button is deleted from DOM 
document.body.removeChild(button);

setInterval
Funções dentro de um setInterval nunca são coletadas, a menos que o intervalor seja limpo:

setInterval(() => {
    let x = 1;
})

Conclusion

Understanding the JavaScript memory model is essential to writing more efficient code and avoiding issues like memory leaks.

Remember:

Primitive types are immutable and stored in the Call Stack as values.
Non-primitive types reside in the Memory Heap and are stored as references.
Exceeding the stack limit causes a Stack Overflow.
Exceeding the available memory causes Memory Leaks.

And if you want to learn more about value and reference variables, read this article I wrote, explaining why we can't compare arrays and objects using ===.

I found it interesting to learn a bit about this and hope you find it helpful too. See you next time!

Why can’t we compare arrays and objects with ===

Leonardo Theodoro — Wed, 29 Jan 2025 10:53:13 +0000

Hi everyone, I decided to write this article to answer a question I’ve always had: why can’t we compare arrays and objects with ===? So, I did some research, and this is what I found about how JavaScript works under the hood.

JavaScript has five data types that are passed by value: boolean, null, undefined, string, and number. These are called primitive types.

JavaScript has three data types that are passed by reference: array, function, and object. Technically, all three are objects, so we can refer to them collectively as objects. These are called non-primitive types.

Primitive Types (Value)

When you declare a variable of a primitive type, it stores the value directly.

const name = 'John'
const age = 25

Variable	Value
name	'John'
age	25

Simple as that.

Non-Primitive Types (Reference)

Variables holding non-primitive values are assigned a reference to that value. This reference points to the location of the object in memory. In this case, the variable stores the reference, not the value itself.

For example:

const fruits = []
fruits.push('Banana')

Here’s a representation of what happens in these lines:

First line:

Variable	Value	Address	Object
fruits	H001	H001	[]

Second line:

Variable	Value	Address	Object
fruits	H001	H001	['Banana']

What happens when we declare a reference variable?

When a reference variable is copied using =, the reference address is copied, not the value. Objects are copied by reference, not by value.

const fruits = ['Banana']
const yellowFruits = fruits

Variable	Value	Address	Object
fruits	H001	H001	['Banana']
yellowFruits	H001

If we add a fruit to the yellowFruits array, we’re also adding it to the fruits array since they share the same reference.

yellowFruits.push('Pineapple')

Variable	Value	Address	Object
fruits	H001	H001	['Banana', 'Pineapple']
yellowFruits	H001

Reassigning a reference variable

When we reassign a reference variable, it replaces the reference, not the value.

let person = { name: 'John' }
person = { name: 'Mary' }

In memory, this happens:

Variable	Value	Address	Object
person	H002	H001	{ nome: 'John' }
		H002	{ nome: 'Mary' }

The old reference still exists, but the variable now points to the new reference.

Why can’t we compare arrays with `===`?

When === is used with reference types (non-primitive data), the condition will only return true if both variables have the same reference. This is because === checks references, not values, for non-primitive types.

const arr1 = ['1']
const arr2 = arr1

console.log(arr1 === arr2) // True

However, if they are different objects, even with the same value, the references differ, so the comparison returns false.

const arr1 = ['1']
const arr2 = ['2']

console.log(arr1 === arr2) // False

Function Parameters

When we pass primitive values as parameters, the behavior is simple: the value is copied into the parameter, as if using =.

const score = 10
const multiplier = 2

function multiply(x, y) {
    return x * y
}

const result = multiply(score, multiplier)

Here, score is 10, multiplier is 2, x is 10, and y is 2. This happens because the value is copied into the parameter.

Variable	Value	Address	Object
score	10
multiplier	2
multiply	H001	H001	function(x,y)
x	10
y	2

Pure Functions

Pure functions don’t affect anything outside their own scope, and all variables used within them are cleared once the function returns a value.

The function multiply above is an example of a pure function.

Impure Functions

Impure functions can receive objects and modify their state outside their scope. This happens because they receive the reference of the value, and any modification to this reference within the function affects the object outside as well. For example:

function changeName(person) {
    person.name = 'Mary'
    return person
}

const john = {
    name: 'John'
}

const mary = changeName(john);

console.log(john) // Mary
console.log(mary) // Mary

This happens because within the function, we’re modifying the value at the reference, which is shared between john and maria.

Making it a pure function

To make this function pure, we create a copy of the object inside the function, manipulate it, and return the copy. This avoids altering the original reference.

Here’s the refactored version:

function changeName(person) {
    const newPerson = JSON.parse(JSON.stringify(person))
    newPerson.name = 'Mary'
    return newPerson
}

const john = {
    name: 'John'
}

const mary = changeName(john);

console.log(john) // John
console.log(mary) // Mary

In this function, we convert the object to a string (a primitive type) and back to an object, creating a new reference. The original reference remains untouched.

Conclusion

Primitive Types: Store values directly in variables.
Non-Primitive Types: Store a reference to the value.
Reference Copying: Objects sharing the same reference reflect changes mutually.
=== Operator: Compares references, not values, in non-primitive types.
Pure Functions: Don’t alter values outside their scope.
Impure Functions: Can modify the state of shared references.
Making Functions Pure: Creating copies prevents changes to original references.

If you’d like to learn more about how variables are stored in JavaScript, check out this article I wrote about the Call Stack and Memory Heap.

Hope you enjoyed this, see you soon!

Before TDD: Why you need to know what Mocks, Stubs, and Spies are?

Leonardo Theodoro — Thu, 09 Jan 2025 17:21:21 +0000

Hello, everyone! Today, I bring a topic that I believe is very interesting. I know there are dozens of articles online discussing TDD, BDD, design patterns for testing, how to write tests, and many other related topics. However, I see very few articles explaining more basic terms within the testing universe—those functions we often use but don’t always fully understand what they mean or how they behave. If you’re just starting to learn about testing and don’t know exactly what the library functions do, this article is for you. Enjoy the read!

What are mocks?

The first thing you might come across as soon as you start writing tests is mocks. Sometimes you already use them but don’t know exactly what they mean. So, let’s dive in.

Mocks are primarily used in unit testing. They are tools used to simulate content, objects, or responses that usually come from an external dependency, or when you need the content to have specific information.

Imagine you’re testing a movie recommendation system. This system fetches a list of movies from an API and returns it to you.

The problem is: if every time you run the tests, the real API is called, it could be slow and inconsistent (movies might vary, or the API could be down), making the tests unreliable.

Alright, Leo, I get the problem, but how does a mock solve this? Well, it’s simple: instead of calling the API, you use its response as a static list of movies. It’s basically “faking” the API response with that list of movies.

In the movie system example, if you want to test a function called fetchMoviesFromAPI() that uses the API to fetch movies, you can create a mock to simulate the API response like this:

// This is the mock
const MOVIES_FROM_API = [
    {
        id: 1,
        name: "Interstellar"
    },
    {
        id: 2,
        name: "Nosferatu"
    }
]

// Here, we’re telling fetchMoviesFromAPI to return our mock instead of calling the real API. This is a stub, which you’ll learn about in the next section.
const fetchMoviesFromAPI = jest.fn().mockResolvedValue(MOVIES_FROM_API)

;(async () => {
    {
        const expectedMovies = MOVIES_FROM_API
        const movies = await fetchMoviesFromAPI()

        expect(movies).toEqual(MOVIES_FROM_API)
    }
})()

With mocks, your tests become more efficient since they don’t depend on external services. Moreover, they gain reliability because you have total control over the returns, allowing the focus to remain on validating the functionality without worrying about potential API instabilities or downtime.

Mocks are static objects that simulate responses from calls or other objects needed for testing.

In the end, it’s like testing a car without using real gasoline. You create a controlled environment to ensure the engine is working before taking it out on the road.

I get mocks, now what are stubs?

Stubs are also testing tools but serve a slightly different purpose. They replace the behavior of functions with something predetermined, often using mocks to return specific values.

Stubs replace the function’s behavior. For example, when I access that movie API, the function won’t make the real call but will look at our mock (the static list of movies).

They also serve as a reminder that our tests shouldn’t depend on external services or the internet.

Let me give you some context: imagine you’re testing an application that calculates the total value of an online purchase. The calculation includes fees fetched from an external service. Every time you run the test, this calculation needs to be done, meaning the external service would need to be called. This could result in a slow, unstable, costly (because the external service might charge per request), and inconsistent test (values could change).

Using a stub, you’ll replace the real service call with a fixed, predefined value (yes, a mock). Instead of calling the fee service, you say: “Always return the value 10 as the fee.”

Imagine you want to test the function calculateTotalPurchase() that sums up the cart items’ values and adds the shipping fee. Using stubs, you replace the shipping fee service with a value that always returns “10” as the shipping fee. Like this:

// Function we want to test
async function calculateTotalPurchase(items, getShippingFee) {
    const shippingFee = await getShippingFee()
    const totalItems = items.reduce((sum, item) => sum + item.price, 0)
    return totalItems + shippingFee
}

// Stub to replace the real shipping service
const getShippingFee = jest.fn().mockResolvedValue(10)

;(async () => {
    // Items in the cart
    const cart = [
        { id: 1, name: "Item 1", price: 50 },
        { id: 2, name: "Item 2", price: 30 }
    ]

    // Calculating the total with the stub
    const total = await calculateTotalPurchase(cart, getShippingFee)

    // Testing the result
    expect(total).toBe(90) // 50 + 30 + 10
})()

This simplifies the test and ensures its reproducibility, meaning it will always work the same way. Moreover, stubs help isolate the test, eliminating the need to worry about the state or availability of the fee API.

In summary, it’s like testing a cake recipe using a measuring cup that always says 200ml of milk instead of measuring the actual amount of milk. This way, you’re only testing if you can mix the ingredients without worrying about whether the milk is being measured correctly.

Mocks, stubs... and finally, what are spies?

We’ve explored mocks, which simulate objects, and stubs, which mimic function behaviors. Now, let’s talk about spies: what exactly do they do?

Spies monitor functions, recording how many times they were called, what parameters they received, and the results of each execution. They allow you to observe the function’s behavior without altering it, ensuring everything is working as expected.

Imagine you’re testing the notification module of your project. Every time an order is completed, the system should send a message to the customer and log an entry. In this case, you only want to make sure these actions are performed but don’t want to replace any of them. With a spy, you monitor these functions without altering their behavior. This allows you to see:

If the function was called
How many times it was called
What arguments it received

For example, if you want to test the completeOrder() function that sends a notification to the customer and logs the entry, with a spy, you can verify:

If the notification function was called
If the log function was called
What arguments these functions received.

// Function we want to test
async function completeOrder(customer, sendNotification, logEntry) {
    await sendNotification(customer)
    saveLog(`Order completed for customer: ${customer.name}`)
}

// Mocks for auxiliary functions
const sendNotification = jest.fn()
const logEntry = jest.fn()

;(async () => {
    // Mock customer
    const customer = { id: 1, name: "John Doe" }

    // Calling the function we want to test
    await completeOrder(customer, sendNotification, logEntry)

    // Checking if auxiliary functions were called
    expect(sendNotification).toHaveBeenCalled()
    expect(sendNotification).toHaveBeenCalledWith(customer)

    expect(saveLog).toHaveBeenCalled()
    expect(saveLog).toHaveBeenCalledWith("Order completed for customer: John Doe")
})()

To conclude, it’s like placing a camera to observe what a chef does in the kitchen. You don’t interfere with what they’re doing; you just check if they’re following the recipe correctly.

So, that’s it! You’ve learned and understood the terms mocks, stubs, and spies, which are fundamental elements for creating reliable and efficient tests. Now you can continue deepening your studies. See you there, goodbye!

Why you should use URL Constructor instead of template literals

Leonardo Theodoro — Wed, 24 Jul 2024 13:20:54 +0000

Hey everyone! Today, I'm sharing a quick tip that improved the semantics of my code significantly.

Often, whether working in frontend or backend development, we need to construct URLs with parameters, right?

I used to write the URLs of my requests like this:

const url = `http://localhost:3000/endpoint?param1=${var1}&param2=${var2}&param3=${var3}`

We agree that this URL is hard to read and maintain; we always need to identify which parts are parameters, which are variables, and which are just Javascript syntax.

To address this semantic issue, I discovered the URL Constructor, which accomplishes the same task but in more efficient and elegant way.

Now, we can rewrite the same code like this:

const url = new URL('http://localhost:3000/endpoint')

url.searchParams.set('param1', var1)
url.searchParams.set('param2', var2)
url.searchParams.set('param3', var3)

The code clearly indicates what it's doing. In the first line, we create the base URL and in the subsequent lines, we add the necessary search parameters.

Done. Now, the variable url contains the same search parameters as before, but now we are using the URL class, making the code much simpler and easier to maintain.

What about you? Have you used the URL class before? Maybe for another purpose? Feel free to share your experiences with me.

Incluindo gráficos em um PDF usando Laravel e Chartjs

Leonardo Theodoro — Thu, 02 Apr 2020 18:46:05 +0000

Se você teve que gerar algum pdf que precisasse utilizar gráficos, sabe o quão difícil é conseguir incluir um gráfico dentro de um pdf, principalmente se você estiver usando gráficos em Javascript.

Referências

Quickchart.io
Chartjs
Laravel

Quickchart.io

Depois de procurar várias formas para incluir os gráficos dentro de um pdf, acabei encontrando um site que se chama quickchart.io, o que ele faz é basicamente transformar gráficos javascript em imagens estáticas que podem ser utilizadas em qualquer lugar, inclusive em um pdf.

Ele funciona da seguinte maneira:

https://quickchart.io/chart?c={type:'bar',data:{labels:[2012,2013,2014,2015,2016],datasets:[{label:'Users',data:[120,60,50,180,120]}]}}

Você envia um query param na url do site com o nome c e o valor é um objeto com as configurações e dados do gráfico, da mesma forma que você cria no chartjs

O resultado dessa requisição é uma imagem png com o gráfico:

Incluindo a imagem no PDF usando Laravel

Nesse caso, estarei usando o dompdf e o Laravel 5.5.

Primeiro passo, tenha os dados na estrutura correta que pede o chartjs.

$chartData = [
  "type" => 'horizontalBar',
    "data" => [
      "labels" => ['Coluna 1', 'Coluna 2', 'Coluna 3'],
        "datasets" => [
          [
            "label" => "Dados", 
            "data" => [100, 60, 20],
            "backgroundColor" => ['#27ae60', '#f1c40f', '#e74c3c']
          ], 
        ],
      ]
  ];

Depois, transforme essa estrutura em json

$chartData = json_encode($chartData);

e mande ela pra URL do quickchart.io usando urlencode

$chartURL = "https://quickchart.io/chart?width=300&height=200&c=".urlencode($chartData);

Sim, é possível você escolher o width e o height do gráfico. A api fornece alguns parâmetros personalizáveis, é só dar uma olhadinha na documentação do quickchart.io 🥰

Feito isso, se você colocar a variável $chartURL dentro de uma tag <img>, a imagem deve aparecer. Porém, eu tive alguns problemas com inserir a variável direto e a imagem não aparecer dentro do pdf, então eu prefiro transformar essa imagem em base64 e ai sim enviar para o pdf.

Para transformar a imagem em base64 é simples:

$chartData = file_get_contents($chartURL); 
$chart = 'data:image/png;base64, '.base64_encode($chartData);

Após, isso a variável $chart já vai possuir o base64 da imagem, como vocês podem notar, eu concatenei no começo da variável o data:image/png;base64,' porque é algo necessário para a tag <img> entender que a fonte da imagem é base64.

Após todos esses passos, estamos prontos para enviar essa variável para o template blade que irá gerar o pdf e incluir o gráfico dentro dele.

Para enviar e incluir a imagem é simples, basta fazer isso:

$pdf = PDF::loadView('report.pdf', ['chart' => $chart]);
return $pdf->stream();

E no arquivo report.blade.php (template do report.pdf)

<img src="{{$chart}}">

Dessa maneira, o gráfico aparecerá corretamente dentro do seu pdf.

Qualquer dúvida, fico a disposição para ajudar.

Meu github
https://github.com/leotheodoro

DEV Community: Leonardo Theodoro

Avoiding Catastrophic Backtracking in Regular Expressions

What is Catastrophic Backtracking?

How does the problem occur in practice?

How to Avoid Catastrophic Backtracking?

1. Avoid Unnecessary Groups

2. Use Boundary Anchors

3. **Use Lazy Quantifiers (*?, +?, ??)

4. Use Atomic Groups ((?>...))

Conclusion

What Are Async Generators and What Are They Used For?

What Are Iterators?

Limitations of Iterators

Generators: Simplifying Iterator Creation

Introducing Async Iterators

Why Use Async Iterators?

1. On-Demand Processing

2. Integration with Asynchronous APIs

3. Performance and Efficiency Improvements

Practical Example: Paginating Data with Async Iterators

Final Considerations

Where do our variables go - A brief guide to Call Stack and Memory Heap

JavaScript Memory Model

What is the Role of the Call Stack?

So, what does the Memory Heap do?

const and Non-Primitive Data

Can Primitive Types Ever "Go" to the Heap?

Garbage Collection and Memory Leaks

Conclusion

Why can’t we compare arrays and objects with ===

Primitive Types (Value)

Non-Primitive Types (Reference)

What happens when we declare a reference variable?

Reassigning a reference variable

Why can’t we compare arrays with ===?

Function Parameters

Pure Functions

Impure Functions

Making it a pure function

Conclusion

Before TDD: Why you need to know what Mocks, Stubs, and Spies are?

What are mocks?

I get mocks, now what are stubs?

Mocks, stubs... and finally, what are spies?

Why you should use URL Constructor instead of template literals

Incluindo gráficos em um PDF usando Laravel e Chartjs

Referências

Quickchart.io

Incluindo a imagem no PDF usando Laravel

4. Use Atomic Groups (`(?>...)`)

`const` and Non-Primitive Data

Why can’t we compare arrays with `===`?