DEV Community: Tássio

Boost Your FrontEnd App Performance with http-front-cache

Tássio — Fri, 17 Jan 2025 17:31:24 +0000

In modern FrontEnd applications, performance is a key factor for user experience. One effective way to enhance performance is by caching the results of service (HTTP requests) functions. This reduces redundant network requests and computations.

In this article, we'll explore the http-front-cache utility, which provides a simple and efficient way to caching on the Frontend.

By the way, it is opensource 🚀

What is http-front-cache?

http-front-cache is a utility designed to cache the results of service functions in the browser. However, it's important to use this utility with caution and adhere to certain constraints:

The data to be cached should not be too large.
The data should not be sensitive.
The data should not change too often.
The service parameters should not change too often (if they change too often, the cache will not be used).

By default, http-front-cache provides two helper functions:

cacheFactory: An extendable cache factory function that accepts a provider (place to save the cache) to cache data. This allows you to extend the caching mechanism and save your cache wherever you need, such as localStorage, sessionStorage, IndexedDB, cookies, in-memory, and etc.

cacheOnSessionStorage: cacheOnSessionStorage is a ready cacheable function that uses cacheFactory and defines Session Storage as a provider. It is an example of what cacheFactory can do. cacheOnSessionStorage was created as Session Storage is one of the most used cache data providers on FrontEnd.

Installation

To get started with http-front-cache, you can install it via npm:

npm i @openish-u/http-front-cache

How to Use http-front-cache

As you might noticed, there are two way to use http-front-cache

1) Using cacheOnSessionStorage

import { cacheOnSessionStorage } from 'utility-http-front-cache';

type Params = string;
type Result = { data: string[] };

const fetchData: ServiceFunction<Params, Result> = async (param: string) => {
  const response = await fetch(`https://dev.to/api/articles?${param}`);
  return response.json();
};

const cachedFetchData = cacheOnSessionStorage(fetchData, 5 * 60 * 1000); // Cache for 5 minutes

// Usage
cachedFetchData('exampleParam').then((result) => {
  console.log(result); // result is the data returned from  fetchData
});

// export cachedFetchData and use where you need

In this example, we define a service function fetchData that fetches data from an API. We then use cacheOnSessionStorage to cache the results of this function for 5 minutes. When cachedFetchData is called, it will first check the cache before making a network request.

Enjoying it? If so, don't forget to give a ❤️ _ and follow me to keep updated. Then, I'll continue creating more content like this_

2) Extending http-front-cache with Custom Providers

import { cacheFactory, ServiceFunction, Provider} from 'utility-http-front-cache';

const customProvider: Provider = {
  getItem: (key) =>
    JSON.parse(localStorage.getItem(key) as string) as Uint8Array,
  setItem: (key, value) => localStorage.setItem(key, JSON.stringify(value)),
  removeItem: (key) => localStorage.removeItem(key),
};

export const cacheOnMyCustomProvider = <TParams extends unknown[], TResult>(
  serviceFunction: ServiceFunction<TParams, TResult>,
  expire: number
): ServiceFunction<TParams, TResult> => {
  return async (...params: TParams): Promise<TResult> => {
    return cacheFactory<TParams, TResult>({
      params,
      expire,
      serviceFunction: fetchData,
      provider: customProvider,
    });
  };
};

// Usage
const cachedFetchData = cacheOnMyCustomProvider(fetchData, 5 * 60 * 1000); // Cache for 5 minutes

// cacheOnMyCustomProvider is your own cache function 😍

cachedFetchData('exampleParam').then((result) => {
  console.log(result); // result is the data returned from  fetchData
});

// export cachedFetchData and use where you need

In this example, we define a custom provider with getItem, setItemand removeItem methods. We then use cacheFactory to create a caching function that uses our custom provider. The same can be done to cache the data where you need it. xP

Buy me a coffee ☕. Hope I have helped you somehow. 🤗

Conclusion

http-front-cache is a powerful utility that can help you boost the performance of your web applications by caching service function results.

For more information and the latest updates, check out the full documentation on GitHub.

See my other articles

Managing Dependabot PRs with dependabot-pr-manager 🤖

Tássio — Fri, 08 Nov 2024 20:32:42 +0000

Managing multiple Dependabot PRs can be a boring task, especially when you have numerous repositories to maintain. The dependabot-pr-manager library simplifies this process by grouping Dependabot PRs into a single PR and closing Dependabot PR. In this article, we'll explore how to use dependabot-pr-manager in your CI pipeline.

By the way, it is opensource. 🚀

BEFORE YOU KEEP REEDING: dependabot-pr-manager only supports Node projects

What does it do?

Currently, dependabot-pr-manager has two main scripts:

Group Dependabot PRs: The merge-dependabot-prs script groups all Dependabot PRs into a single PR, allowing you to review and update the changes before merging.
Close Dependabot PRs: The close-dependabot-prs script closes all open Dependabot PRs.

How to use it?

Installing

UPDATE(12/23/2024): If you use the old utility-dependabot-pr-manager, you can migrate to the new prefix @openish-u/dependabot-pr-manager 5.0.1 version. The packages are the same, only the prefix has changed.

Install dependabot-pr-manager as a devDependency. Example:

npm i @openish-u/dependabot-pr-manager --save-dev

On CI

Below is an example of how to set up a GitHub Action (you can adapt to other CI services) to run the dependabot-pr-manager script on the first day of every month (at 09:00 UTC) and allow manual triggering via a GitHub button. Additionally, it includes a job to close the Dependabot PRs when the created PR is commented with "[dependabot-pr-manager] close prs".

Create a file named .github/workflows/dependabot-pr-manager.yml in your repository:

[UPDATED] 12/02/2024: changed cron from 0 9 * * 1 to 0 9 1-7 * 1. Now, it is running every first Monday of each month at 9am (UTC).

name: Group and Close Dependabot PRs

on:
  schedule:
    - cron: '0 9 1-7 * 1' # Runs at 09:00 (UTC) on the first day of every month
  workflow_dispatch: # Allows manual triggering via GitHub button
  issue_comment:
    types: [created]

jobs:
  merge-dependabot-prs:
    if: github.event_name == 'workflow_dispatch' || github.event_name == 'schedule'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '18'

      - name: Install Yarn
        run: npm install -g yarn

      - name: Install dependencies
        run: yarn install

      - name: Set up Git
        run: |
          git config --global user.name "dependabot[bot]" # change to the user that will merge the PRs
          git config --global user.email "49699333+dependabot[bot]@users.noreply.github.com" # change to the user that will merge the PRs

      - name: Run merge-dependabot-prs
        run: |
          npx merge-dependabot-prs \
            --repoUrl=https://github.com/open-ish/utility.git \
            --combinedBranch=ci/combined-dependabot-updates \
            --mainBranch=main \
            --githubToken=${{ secrets.YOUR_GIT_HUB_TOKEN }} \
            --repoOwner=open-ish \
            --repoName=utility

  close-dependabot-prs:
    if: github.event.issue.pull_request && contains(github.event.comment.body, '[dependabot-pr-manager] close prs')
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '18'

      - name: Install Yarn
        run: npm install -g yarn

      - name: Install dependencies
        run: yarn install

      - name: Run close-dependabot-prs
        run: |
          npx close-dependabot-prs \
            --githubToken=${{ secrets.YOUR_GIT_HUB_TOKEN }} \
            --repoOwner=open-ish \
            --repoName=utility

merge-dependabot-prs Job: This job runs the merge-dependabot-prs script to group Dependabot PRs into one.
close-dependabot-prs Job: This job runs the close-dependabot-prs script to close the Dependabot PRs when the pull request created from dependabot-pr-manager be commented with '[dependabot-pr-manager] close prs'.

Enjoy it? Don't forget to like the article and starring the repository! ⭐

Package params

--repoUrl(required): The repository URL;
--combinedBranch(required): The branch that will be created with the combined PRs;
--mainBranch(required): The main branch of the repository;
--githubToken(required): The GitHub token;
--repoOwner(required): The repository owner;
--repoName(required): The repository name;
--installDepsCommand: The command to install the dependencies. Default: yarn install
--filesToCommit: Files to be committed on the pull request. Default: package.json yarn.lock

Examples

See this PR example

Grouping Dependabot PRs

Closing Dependabot PRs after comment [dependabot-pr-manager] close prs

Conclusion

The dependabot-pr-manager library is a nice tool for managing Dependabot PRs in your repositories. By automating the process of grouping and closing PRs, you can save time and ensure that your dependencies are always up to date. Try integrating dependabot-pr-manager into your CI pipeline and share your experience commenting on the article and/or repository.

Unit Testing: A Hands-On Guide with Real Examples - React + Vitest (p.1)

Tássio — Fri, 10 May 2024 12:01:30 +0000

In the world of software development, unit testing is a vital practice that ensures our code behaves as expected. It's the safety net that catches bugs before they sneak into the final product. But understanding the theory is one thing, applying it is another. That's why in this article, we're going to roll up our sleeves and dive into the practical side of unit testing.

For this first article (yes, I'm thinking of creating more steps later 👀) we are going to see my EditableTypography component. Let's see it working to understand better:

Cool, isn't it?! You can even put your hands on it by accessing my project

Stack and source code

React
Typescript
Vitest
testing-library

Great! Let's see the source code (by the way, the project is open source):



// ...more code
const EditableTypography = ({
  label,
  tag,
  className,
  updateText, // on update text function
}: EditableTypographyTypes): JSX.Element => {
  const [isEdit, setEdit] = useState(label === '');
  const [newText, setNewText] = useState(label);

  const handleResetState = () => {
    setEdit(false);
    setNewText(label);
  };

  const onKeyDown = (event: React.KeyboardEvent<HTMLInputElement>) => {
    const key = event.key;
    const isEsc = key === 'Escape';
    const isEnter = key === 'Enter';

    if (!newText) return;

    if (isEsc) {
      handleResetState();
      return;
    }

    if (!isEnter) {
      return;
    }

    updateText(newText);
    setEdit(false);
  };

  return (
    <>
      {isEdit ? (
        <Styles.TextInput // styling with styled-components
          // this will be used later to select the input on the test
          data-testid="editable__input"
          label=""
          value={newText}
          placeholder="Edit me"
          onKeyDown={onKeyDown}
          onChange={(event) => setNewText(event.target.value)}
          title="Press Esc or click outside to cancel"
        />
      ) : (
        <Styles.Typography
          onClick={() => setEdit(true)}
          // this will be used later to select the Typography block on the test
          // I'm using diff selectors to teaching purposes
          title="Click to edit"
        >
          <Typography
            tag={tag}
            label={label || 'editing...'}
            className={className}
          />
        </Styles.Typography>
      )}
    </>
  );
};

OBS: I'm removing some pieces of the code to make it clear. It uses a Typography component and applies the Open-Closed Principle (from SOLID) by extending Typography functionalities instead of including the edit mode to Typography responsibilities.

Defining the test cases

There are two alternatives to define the cases we must test: imperatively and declaratively.

The first one is by detecting the conditions/logic in the code and the another is focused on the component behavior (usually defined with/by the UX team).

Both approaches have pros and cons and might complement each other depending on the case, but the declarative approach tends to create more descriptive tests in components case. In this article, let's go deeper into the declarative one, but also there is a section about imperative.

Imperative approach (short explanation)

On the imperative approach, I usually split out the source code to get what test. Generally, splitting the component code into two pieces before defining the tests:

nodes conditions* (every condition in the node block)
helpers/functions* conditions (every condition out of the node block)

*conditions are every logic in our code that can create different behaviors. It is represented by logic operators such as if, else if, &&, ||, >, <, ===, and so on. Once the idea of the unit test is to ensure our code behaves as expected, we must guarantee that the logic created is working as we want it to.

Imperative approach - Nodes conditions

Focusing on the node block, there are 2 operators:

ternary operator (?:): to validate which node is rendered by the isEdit flag;
OR operator (||): to show a fallback ("editing...") while the label is "" (it is used to handle async operations)



return (
    <>
      {isEdit ? ( // ternary operator
        <Styles.TextInput // styling with styled-components
          data-testid="editable__input"
          label=""
          value={newText}
          placeholder="Edit me"
          onKeyDown={onKeyDown}
          onChange={(event) => setNewText(event.target.value)}
          title="Press Esc or click outside to cancel"
        />
      ) : (
        <Styles.Typography onClick={() => setEdit(true)} title="Click to edit">
          <Typography
            tag={tag}
            label={label || 'editing...'} // OR operator
            className={className}
          />
        </Styles.Typography>
      )}
    </>
  );

Even the ternary and OR operator have two cases for cover:

isEdit can be true or false
label can be "" or different of ""

So, in the code block, there are 4 cases to cover. Does it mean 4 test cases are required to cover the code block? Not necessarily, once more than one condition can be executed together. In this case, for example:

If the isEdit is true, the label is not rendered (1 condition);
if the isEdit is false, the label can be "" or diff of "" (mode 2 conditions, once they are executed together)

Resuming, we could create 3 test cases to cover the four conditions.

The same should be applied to the helper/function block, but now we will define the cases using the declarative approach and from there create the tests.

Enjoying it? If so, don't forget to give a ❤️ and follow me to keep updated. Then, I'll continue creating more content like this

Declarative approach

On the declarative approach, the test cases are created based on the component behaviors (usually, defined before it being created and with/by the Ux team). Those behaviors can be divided into 3 categories:

Empty state: does it have props that can start "empty" (without value)?
Failure state: can it get an error?
Happy state: how should it behave?

In the EditableTypography case, there is no Failure state, but there are even Empty and Happy states. So, let's define them:

Empty state behavior:

(case1) On the first render, the component should show a placeholder "Edit me" as the label is empty;

(case2) On the first edit, the component should show a fallback text "editing..." while label is empty;

Happy state behavior:

(case3) When the label has a value and the component is not in the edit mode, the component should render the label value;

(case4) When it enters the edit mode, the component should close the edit mode if the user has clicked on the Esc button and not set the new value;

(case5) When it enters the edit mode, the component should close the edit mode if the user has clicked on the enter button and has a value to be set;

OBS: It could also be used to use the TDD approach: where the tests are created before the development has started.

Cool! Once defined the component behaviors, it is possible to create the test cases. First, let's create the titles. It is a convention to start with "should" (it is not required, obviously) and I'll use it. We are going to use the behaviors defined so far to create the test titles:



it.todo('Should show a placeholder as the label is empty - first render') // case1

it.todo('Should show a fallback text "editing..." while label is empty - first render') // case2 

it.todo('Should render label as it is not edit mode') // case3

it.todo('Should close the edit mode if the user has clicked on the Esc button and not set the new value') // case4

it.todo('Should close the edit mode if the user has clicked on the enter button and has a value to be set') // case5

Cases defined, let's create the tests (finally!!)!

It starts by importing and setting which is required for all tests.



import React from 'react';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

import { vi } from 'vitest';

import EditableTypography from './EditableTypography';

const user = userEvent.setup(); // userEvent instance to simulate user events (such as clicks and input data)

TIP: For the test creation, you can also think that once there is an input (WHEN) it should have an output (THEN/ASSERTION). For example:

WHEN label is empty and it is first render (user has not set data) THEN it should render the placeholder

Which comes after WHEN is the component's props and mocks, which comes after THEN is what ensures it has happened as expected

case1:



// ...more code

 it('Should show a placeholder as the label is empty - first render', () => {
    // WHEN label is empty and it is first render (user has not set data)
    const updateTextMock = vi.fn();
    render(
      <EditableTypography
        label="" // label is empty
        tag="h1"
        className="testClass"
        updateText={updateTextMock}
      />
    );

    // selecting the input on the page
    const input = screen.getByTestId('editable__input') as HTMLInputElement;

    // THEN it should render the placeholder (we ensure it by expecting input has the placeholder)
    expect(input).toBeInTheDocument();
    expect(input.placeholder).toBe('Edit me');
  });

case2:



// ...more code

it('Should show a fallback text "editing..." while label is empty - first render', async () => {
    // WHEN label is empty and user has updated the value
    const updateTextMock = vi.fn();
    render(
      <EditableTypography
        label="" // label is also empty
        tag="h1"
        className="testClass"
        updateText={updateTextMock}
      />
    );

    const inputElement = screen.getByTestId('editable__input');

    //typing New title on the input and clicking on enter btn
    await user.type(inputElement, 'New Title{enter}');

    // THEN it should call the setter function (updateTextMock)
    // and show 'editing...' text on the scree
    expect(updateTextMock).toHaveBeenCalledWith('New Title');
    expect(screen.getByText('editing...')).toBeInTheDocument();

    // OBS: as updateText can be async, it might not update the label immediately.
    // Once the updateTextMock is only a mock without handling the state, it will not update the label,
    // which is totally fine to the test once updateText logic is outside EditableTypography responsibilities.
  });

case3:



// ...more code

it('Should render label as it is not edit mode', () => {
    // WHEN label has value
    const updateTextMock = vi.fn();
    render(
      <EditableTypography
        label="Old title" // now it has a value
        tag="h1"
        className="testClass"
        updateText={updateTextMock}
      />
    );

    // it is using queryByTestId instead of getByTestId
    // because query* is recommend to case where the element is not in the page
    // (and also get* does not work in this cases xP)

    const inputElement = screen.queryByTestId('editable__input');

    // THEN show the label value and do not show the input
    expect(screen.getByText('Old title')).toBeInTheDocument();
    expect(inputElement).not.toBeInTheDocument();
  });

case4:



// ...more code

it('Should close the edit mode if the user has clicked on the Esc button and not set the new value', async () => {
    // WHEN label has value and user has clicked on shift btn
    const updateTextMock = vi.fn();
    render(
      <EditableTypography
        label="Old title"
        tag="h1"
        className="testClass"
        updateText={updateTextMock}
      />
    );

    const typographyElement = screen.getByTitle('Click to edit');

    // it enters the edit mode
    await user.click(typographyElement);

    const inputElement = screen.getByTestId('editable__input');

    // it adds "New Title" and tries to click on shift (shift btn does not do anything - only enter)
    await user.type(inputElement, 'New Title{shift}');

    // THEN the edit mode keeps on
    expect(updateTextMock).not.toHaveBeenCalled();
    expect(inputElement).toBeInTheDocument();

    // WHEN label has value and user has clicked on esc btn
    await user.type(inputElement, '{escape}');

    // THEN the edit mode has closed and the old label value is showed
    expect(updateTextMock).not.toHaveBeenCalled();
    expect(inputElement).not.toBeInTheDocument();
    expect(screen.getByText('Old title')).toBeInTheDocument();
  });

case5:



// ...more code

it('Should close the edit mode if the user has clicked on the enter button and has a value to be set', async () => {
    // WHEN label has value and user has updated the value
    const updateTextMock = vi.fn();
    render(
      <EditableTypography
        label="Old title"
        tag="h1"
        className="testClass"
        updateText={updateTextMock}
      />
    );

    const typographyElement = screen.getByTitle('Click to edit');

    // it enters the edit mode
    await user.click(typographyElement);

    const inputElement = screen.getByTestId('editable__input');

    // it clears the input (once the there is Old title label)
    await user.clear(inputElement);
    //  it adds "New Title" and enters
    await user.type(inputElement, 'New Title{enter}');

    // THEN the edit mode has closed and the new label value is shown
    expect(inputElement).not.toBeInTheDocument();
    expect(updateTextMock).toHaveBeenCalledWith('New Title');
  });

Nice!! We did it!

Checking the local coverage report file

If the tester engine has coverage configured, it generates a report file with information regarding code coverage (it means, how much the test created validates that component's logic). It is helpful to ensure that the tests created are validating the logic in the component.

Generally, this file (there are different formats, such as .html) is in the ./coverage folder at the project's root.

What a great! We have got 100% code coverage (I might create a article regarding coverage in the future 👀).

Buy me a coffee ☕. Hope I have helped you somehow. 🤗

Next steps

In the next article (in progress), let's explore more behaviors to the EditableTypography: click outside (clicking outside might close the edit mode) and focus/select(focus in the text field and select all label text when entered in the edit mode)

Follow me to let you know.

You can find the final file version here

See my other articles and my open source project

Behind the Code: Understanding the Purpose of Systems and the Role of Developers

Tássio — Tue, 30 Apr 2024 11:55:17 +0000

Nothing more modern to talk about than the development world, even if sometimes systems pass unsee for who is using them. Fortunately, it is so overvalued for those who are behind the scenes that you can find more and more articles and forums about it.
I'm going to talk about what we must keep in mind when creating value systems and what we must do to be a valued developer.

System's purpose

It's unarguable that systems come to stay. In just a blink of an eye, we can see a lot of systems around us.
They are there when we need to pay a bill, buy a game, share some posts, talking with someone far away. But, have you ever tried defining what a system means or why we need them? I know that sounds a bit essential, but sometimes it looks like some developers don't know the purpose behind creating systems.

The merriam-webster dictionary defines systems as:
a regularly interacting or interdependent group of items forming a unified whole.

Thinking about the literal definition, that sounds ok, but regarding purpose (business mindset), systems could also be defined as a tool (or a solution) to solve a main problem. Sometimes, this main problem can be composed of many small problems. As many more small problems the system solves it's getting better. So, in other words, systems can help people to get better lives, since solving problems is their purpose. Do you get how meaningful it is?
Keep in mind the next time you are coding one: It is not about who does or what is used, but for who can be helped.

Enjoying it? If so, don't forget to give a ❤️. Then, I'll continue creating more content like this

Developer’s roles

After putting the purpose of the system on the tablet, it's essential to understand the developer's roles.

If you are new to this world, you are probably thinking about developers at coding. For sure, that makes sense. The most important skill of any developer is that, but is it enough?

In that first moment, let’s go through the general good developer responsibilities. But soon, I also will create a post with the difference between Juniors, Middles, and Seniors' skills.

Developer’s responsibilities:

Coding/making the system grow.
Ensuring quality and security in the system
Finding ways to improve the application (thinking on performance, accessibility, architecture, and so on), proactively
Warning the company about the system's needs and the development team's needs, proactively
Scalability
Smartly deliveries (coding never stops, so we must split our deliveries to give value)
Creating smartly processes/flows (as git-flow)
Creating ways to be more prevented than reactive, principally to avoid crashing
Sharing knowledge
Taking care of the system's health

As you can see, coding is not the only developer's responsibility. I like to think that developers are owners of the system, so they must take care of it. In other words, it's expected that you will mind all the stuff that might impact the system.

Never forget: If it’s to be, it’s up to me

You're probably wondering: How about programming languages? Frameworks, and so on?

Yeah, again: these are the first things we think about development words, but actually, many hard skills that we need are volatile, so it's impossible (and, to be honest, unnecessary) to know all of them. But, these responsibilities and soft skills are needed and they would make you a valued professional because hard skills are more accessible to learning and teaching than soft skills and responsibilities.

Now, you could work on a company using React, but tomorrow, you could receive an excellent opportunity to work with Vue and will need to study it - and that's ok because it is not about who does or what is used, but for who can be helped. Taking care of the system and having these responsibilities will be necessary whatever you go.

See my other articles

Mastering Code Review: A Guide for Reviewers and PR Creators

Tássio — Sat, 27 Apr 2024 14:19:45 +0000

Code reviews are essential for code quality, team collaboration, and to make sure that best practices are followed in the development process. Guess no news so far, however, effective code reviews requires more than just looking for bugs or syntax errors. Let's take a look in the best practices for conducting code reviews from the perspective of the reviewer and the pull request creator.

For Reviewers 🔎

Be constructive: Provide feedback in a constructive and respectful way. Focus on improving the code rather than criticizing the developer. Being polite is always good xP
Understand the context: Take the time to understand the purpose and requirements. This will help you provide more relevant feedback.
Review the code, not the person: Remember that code reviews are about improving the code, not attacking the developer.
Be specific: Provide specific comments and suggestions. Avoid vague or general feedback that may confuse the developer (one of the most important, in my opinion).
Prioritize issues: Identify critical issues that need immediate attention and non-critical one that can be addressed in the future. This will help the developer focus on the most important.
Offer alternatives: Instead of just pointing out problems, suggest alternative solutions or improvements.
Consider the bigger picture: Think about the impact of the changes on the overall system. Consider scalability, maintainability, and performance aspects during the review.
Remember of deadlines: Review code promptly to avoid delaying the development process. If you need more time, communicate it to the pull request creator.
Avoid "Pull Request Friendship" : Do not approve a pull request just because the creator is a friend or because you have faith in their deliveries. Every pull request should be reviewed objectively, based on the quality of the code and its adherence to project standards and best practices. This ensures fairness and maintains the integrity of the codebase.

Enjoying it? If so, don't forget to give a ❤️_ and follow me to keep updated. Then, I'll continue creating more content like this_

For Pull Request Creators 💻

Prepare your code: Before submitting a pull request, make sure your code is clean, well-structured, and follows the project's coding conventions. This will make the review process smoother.
Utilize repository features: Assign the pull request to yourself, use a clear and descriptive title and apply labels. Maintaining an organized repository is straightforward, easier fot future filtering and searching, and fosters a healthy codebase to work with.
Provide context: Include a clear description of the changes made and the problem being solved. This will help reviewers understand the purpose of the code and also make easier to future investigations.
Be open to feedback: Be receptive to feedback and willing to make changes. Remember that code reviews are (should be) an opportunity to improve the quality of your code.
Engage in discussions: Respond to comments and questions from reviewers.
Learn from the review: Use the feedback received during the code review to improve your coding skills. Take the opportunity to learn from more experienced developers.
Address all comments: Address all comments and suggestions made by the reviewers. If you disagree with a comment, provide a clear explanation and discuss it with the reviewer.
Test your changes: Before marking the pull request as ready for merge, ensure that your changes have been thoroughly tested and do not introduce any regressions.
Keep it concise and context-specific: Concentrate on delivering within the context and avoid modifying files outside the scope. Smaller pull requests are easier to review and reduce the overall time for pull request approval.
Be grateful: Show appreciation to the reviewers for their time and effort in providing feedback. A simple thank you is enough and creates a positive code review culture. ❤️

Buy me a coffee ☕. Hope I have helped you somehow. 🤗

See my other articles and my open source project

Loading chunks on demand - beyond the router (part 2)

Tássio — Fri, 10 Nov 2023 17:38:17 +0000

It's time to control when your application requests the chunks of your page and optimize the loading.

Let's look at how to split up the chunks and load them at the right time. I'll show it with a personal project. The stack is as follows:

React (SPA);
Vite;

The same is applicable (changing the syntax, obviously) to any other JS frameworks and bundler tool, consult the doc to know how.

NOTE: This is the second part, see the first post here

Reducing the size of the main chunks

Let's dig deeper into the main chunk files and explore how to reduce them. By the way, do you know who the main chunk files on SPAs (Single-page applications) are? Usually, tools such as Vite and Wepack create two main chunk files: index.hash.js and vendor.hash.js:

index: there are crucial application codes, such as App.tsx code;
vendor: All production dependencies (package.json > dependencies);

Why are they referred to as 'main' files? Both the index and vendor files are the first to load and are essential in all Single Page Application (SPA) routers. That means all code included (or not) in them will impact the page load.

Note: Vite has removed this behavior since the 2.9 version. Now, by default, the index also has the production dependencies code. Even though Vite doesn't split them by default, it provides a plugin to do it for you:

import { splitVendorChunkPlugin } from 'vite';

export default defineConfig({
  plugins: [
    react(),
    splitVendorChunkPlugin()
]})

It's vital to keep your eyes on them and control their size, once those chunks tend to be the biggest of the application.

Exploring the chunk sizes with rollup-plugin-visualizer

I’m using the rollup-plugin-visualizer to explore the chunk sizes of the project. This way, I can figure out if there are unnecessary chunks on them.

The Visualizer shows what the final bundle looks like, including each chunk size by hovering it. Seeking our main chunks (hovered on the gif):

vendor.hash.js: 94.89kb gzip
index.hash.js: 17.99kb gzip

On the same gif, it’s possible to see that the components folder is included on index.hahs.js. Some components in that folder do not need to be global, then it’s an opportunity to reduce the index.hash.js chunk size.

Seeking on the project, the TextInput component is used in some places and it has a unique import to the uniqid lib.

If seek TextInput and uniqid, the first one is found on the index and the other on the vendor. It's amazing once it's possible to reduce index and vendor sizes.

Importing TextInput (and uniqid) dynamically

So, what is the strategy? Once TextInput is not global, there's no need to retain its code in the index chunk. Let's utilize the Lazy API to extract its code from there. Additionally, since uniqid is imported only in TextInput, it will be included in the new chunk and removed from the vendor chunk.

It's necessary to change all TextInput imports to make it work. Each import should use the Lazy API (n this case, there are 3 TextInput imports):

// import TextInput from '@/components/TextInput/TextInput'; // current code

// using lazy API
import { lazy } from 'react';
const TextInput = lazy(
  async () => await import('@/components/TextInput/TextInput')
);

Note: I have reduced the whole code to teaching purpose, but at the bottom, you can find the commit and the full source code. Read the comments to understand.

Once done, let's see the final bundle.

Now, TextInput has its chunk and it's no longer included on the index chunk. Additionally, the uniqid was also included on the new chunk and removed from the vendor chunk.

vendor.hash.js: 93.24kb gzip (1.65kb less size, no longer has uniqid code)
index.hash.js: 17.24kb gzip (0.75kb less size, no longer has TextInput code)
TextInput.hash.js: 2.48kb gzip (new chunk with TextInput and uniqid)

Now, TextInput and uniqid will be downloaded, parsed, and compiled by the browser only when they are required. It's possible to see this on the Network tab, where the About router does not use TextInput.hash.js chunk, but Login does:

Conclusion

Well, you might be wondering: is it worth it for just a 2.4kb reduction in code? Indeed, this is just an example, and we can extend our exploration to other components beyond TextInput. However, it's essential to recognize that good performance results from a combination of improvements that collectively enhance the overall user experience of your application. Additionally, these concise examples in the code serve as reminders for teammates to continuously seek opportunities for code optimization.

See my other articles

Web Workers: Avoid overloading the main thread

Tássio — Sat, 19 Aug 2023 15:25:09 +0000

Is your application overloading the main thread? In this article, I show a practical example that might make you start using Web Worker - let's take a look at how them can avoid the main thread getting overloaded.
I use a personal project to show it - React (SPA).

The same applies to any other js frameworks.

What are Web Workers?

It requires an exclusive article to explain Web Workers, but I'm gonna try a short explanation.

First, to understand it, you must take in mind your frontend application runs in the browser's main thread: the thread where most tasks are run to make your application accessible. It's responsible to compile files, execute files, and also handle user interactions (events and input).

Everything is processed task by task, one by one. This means the main thread can't process a task to compile a JS file and treat an input event at the same time, for example.

Web Workers are a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface.

This is the MDN definition of Web Workers. In other words, Web Workers is a way to run js scripts in their thread, which can avoid overloading the main thread.

Project

Before getting into the practical code, let's see the project we gonna work on and what changes.

This is the current project, it fetches my Dev.to articles and show them in the view, besides it loops into the articles array and gets all tags (creating a unique array with all tags). The tags array is used to render the chips in the modal - which will be used to filter in the future.

Once said, the idea is to explore the tags array created using the main thread only VS also using a Web worker.

Note: It's not a React article, so I won't focus and the whole view code, but the source code is in the final.

Let's see how it will be processed:



// Articles.tsx (the view component)
//...more code

const handleTags = () => {
 const map = new Map();
 // articles is my Dev.to articles
 for (const article of articles) {
  for (const tag of article.tag_list) {
    map.set(tag, tag);
  }
 }
// set the tags state
 setTags(Array.from(map.values()));
}

// call handleTags when articles GET has finished
useEffect(() => {
    !isLoading && handleTags();
}, [isLoading]);

//...more code

When the Articles view is rendering, It loops into the articles array and the tag_list array then set each item into the map. Then, gets the map object and converts an array. We see it in the modal:

As you can see, this code has an O nˆ2 complexity, as there is a for loop inside another for loop. To make it more interesting and easier to see the difference, let's put an extra for:



// Articles.tsx (the view component)
//...more code

const handleTags = () => {
 const map = new Map();
 // articles is my Dev.to articles
 for (const article of articles) {
  for (const tag of article.tag_list) {
    map.set(tag, tag);
  }
 }
// extra code, huge operation
for (let idx = 0; idx < 1000000000; idx++) {
  idx++;
}
// set the tags state
 setTags(Array.from(map.values()));
}

// call handleTags when articles GET has finished
useEffect(() => {
    !isLoading && handleTags();
}, [isLoading]);

//...more code

This code will help us understand the difference between use and don't Web Workers.

How to measure the impact of using Web Workers

First, I put more elements in the view to see:

A "working..." text to see while the handleTags is processing;
A checkbox to try to click while the handleTags is processing;

The second it's the most important, the idea is to show how the main thread does not do more than one task at the same time, later.

Second, I will use the browser's performance tab to detect how the handleTags function takes a long, besides simulating a slower CPU.

Ok, now we're ready to compare the execution of the handleTags on the main thread only VS using Web Worker.

Using the main thread only

So, first, I tried to click on the checkbox element while the handleTags was processing.

Do you see it? I'm trying to click on the checkbox, but the element keeps unchecked. That shows us what happens when a user tries to do something while the main tread is busy.

Note: if you wanna try it by yourself, I put the source code in the final with the instructions.

Looking in the performance tab, we can see a long task shown.

Two seconds were needed for the main thread to execute it. In other words, the user couldn't do anything for 2 seconds.

Enjoying it? If so, don't forget to give a ❤️_ and follow me to keep updated. Then, I'll continue creating more content like this_

Using the main thread and a Web Worker thread

As Web Workers have their thread (and they don't have access to the DOM), we must create a communication between the main thread and the Web Worker thread. This way we can use the Web Worker thread when required only.

First, let's create a new file that will be used to create a Web Worker:



// sw.ts file
import { IArticle } from '@/models/Article';

// self is like the globalThis, but for Web Workers (there is no global window on the Web Worker thread)
// onmessage is the callback executed when the main thread asks for a Web Worker execution

self.onmessage = (e: MessageEvent<IArticle[]>) => {
  const map = new Map();
 // e.data is my Dev.to articles
 for (const article of e.data) {
  for (const tag of article.tag_list) {
    map.set(tag, tag);
  }
 }
// extra code, huge operation
for (let idx = 0; idx < 1000000000; idx++) {
  idx++;
}

// Once execution has finished, Web Worked sends a message to the main thread (hey, I'm done. Get the result).
 self.postMessage(Array.from(map.values()));
};

So, we moved the code from the handleTags to a separate file, using the Web Worker syntax.

The code is now on the onmessage callback (which is executed when the main thread asks for a Web Worker execution), then we send back the result to the main's thread. But how about the component?



// Articles.tsx (the view component)
//...more code

// creating a Web Worker instance. It asks for a path file (our sw.ts in this case)
const swArticles: Worker = useMemo(
 () => new Worker(new URL('./sw.ts', import.meta.url)),
 []
);

const handleTags = () => {
// handleTags there is no more looping, but it's responsible for asking a Web Worker execution outside the main thread

 if (window.Worker) { // validate if there is Worker on the window
   // hey Web Worker thread, do something to me with this data
    swArticles.postMessage(articles);
  }
}

// call handleTags when articles GET has finished
useEffect(() => {
    !isLoading && handleTags();
}, [isLoading]);

// when Web Worker sends the result
 useEffect(() => {
    if (window.Worker) {
      swArticles.onmessage = (e: MessageEvent<IArticle['tag_list']>) => {
// set the tags state
        setTags(e.data);
      };
    }
  }, [swArticles]);

//...more code

Ok, now our code changed a bit:

First, it creates a Web Worker instance, passing the sw.ts path on the constructor. This is stored on the swArticles state, which is a Web Worker instance now.

When the articles GET has finished, it calls the handleTags, which now there is just a postMessage from swArticles. This is enough to process something on the Web Worker thread - the code on the sw.ts file

When the Web Worker finishes (self.postMessage), it sends back the result, which is listened to, and changes the tags state by calling setTags.

Let's see our view behavior now:

Great! Now, it's possible to click on the checkbox element even when the handleTags is executed. The main thread says thanks!

how about the performance tab?

Now handleTags takes 0.13ms!!!

Wait!!! What happens with the loops?

Great question! On the performance tab, below the main thread graph, we see the Worker thread:

This means the Web Worker has done the heavy job.

Try yourself

You can simulate both cases by cloning the repo, then changing to the feat/main-thread-vs-web-workers branch. After that, running the project you might have different behaviors by passing a query parameter:

Normal behavior: it uses Web Worker but has not the checkbox element;
Passing sw=on (http://localhost:3000/articles?sw=on) query parameter: it uses Web Worker and has the checkbox element;
Passing sw=off (http://localhost:3000/articles?sw=off) query parameter: it does not use Web Worker and has the checkbox element;

Try it and see the difference!

Buy me a coffee ☕. Hope I have helped you somehow. 🤗

Conclusion

In this article, we saw the Web Worker power a bit and how it helps to avoid overloading the main thread. This is a teaching example, but for sure it's something we must keep in mind as FrontEnd developers. Explore it!

See my other articles

Barrel files and why you should STOP using them now

Tássio — Sat, 12 Aug 2023 14:23:39 +0000

Small decisions can also have big impacts on applications. When developers start using barrel files they might seem like a harmless pattern, but they aren't.

[UPDATE Mar, 23th of 2024]:
BEFORE YOU KEEP READING: this article and its metrics were created thinking on final front-end applications. Those that final users navigate such as dev.to and my source project. So, if you have been using Barrel files in any other context, such as packages, it (Barrel files) might fit you as expected. Take a look at this amazing comment from
@kasper573.

What are barrel files?

Barrel files are an easy exportation pattern that allows developers to import different files from a unique path.

Let's see an example:

// ./barrelFiles/used.ts
export const HEY = 'hey used';

// ./barrelFiles/notUsed.ts
export const HEY_NOT_USED = 'hey NOT used';

// ./barrelFiles/index.ts
export { HEY_NOT_USED } from './notUsed';
export { HEY } from './used';

/*
This is a barrel file, which will be used as a unique path to import any files into barrelFiles folder (such as ./used).
*/

Using it:

// ./Component.tsx

import { HEY } from './barrelFiles'; // instead of use './barrelFiles/used'

In the first touch, that looks amazing, doesn't it? They are in terms of Dev Experience, but it costs a lot!

What is the Barrel files cost into the app bundle?

One crucial question you must keep in mind about barrel files: What is imported when I use something from them? Does it import only what I use?

Let's see it with examples. Right, Let's add two more files to our barrel file and add some console.log to see how they work:

// now there are 4 files in barrelFiles folder

// ./barrelFiles/used.ts
export const HEY = 'hey used';
console.log('%c Im used xD', 'color: green;');

// ./barrelFiles/notUsed.ts
export const HEY_NOT_USED = 'hey NOT used';
console.log('%c WAIT! Im NOT used', 'color: red');

// ./barrelFiles/notUsed1.ts
export const HEY_NOT_USED_1 = 'hey NOT used 1';
console.log('%c WAIT! Im NOT used 1', 'color: red');

// ./barrelFiles/notUsed2.ts
export const HEY_NOT_USED_2 = 'hey NOT used 2';
console.log('%c WAIT! Im NOT used 2', 'color: red');

And the barrel file:

// ./barrelFiles/index.ts
export { HEY_NOT_USED } from './notUsed';
export { HEY_NOT_USED_2 } from './notUsed2';
export { HEY_NOT_USED_1 } from './notUsed1';
export { HEY } from './used';

Well, getting back to the questions, it's expected if I import HEY, I only import ./used file content. So let's do this by importing it into my personal project where you find more articles like this:

// ./Component.tsx

import { HEY } from './barrelFiles'; // I wanna use HEY, only

Do you see? Even though only HEY is used, it shows all console.log which means all files are imported.

Now, not importing from the barrel file.

// ./Component.tsx

import { HEY } from './barrelFiles/used'; // I wanna use HEY, only

Importing directly one console.log is shown.

You might be wondering: why would there be files not used in my project?

That's a good question. Well, some points about it:

In this example, there are few files, but how about a huge project using dozen barrel files? Likely there would be not used files. If you work on a monorepo, it might have shared folders used for many apps. Creating patterns that avoid team-mattes (and you) doing things wrong is the best thing you can do as a developer;
Even though tools such as Vite and Webpack optimizing bundle and avoid to use re-import chunks, the better way to make sure you opmitizing as much as possible is understanding things work on the application. To understand it, see the next screenshots.

Let's see the bundle difference now (please, as it's a teaching example, the difference is short. Scale it up to understand the impact). See this comment with real numbers

Using the barrel file (189,83kb):

No barrel file (189,67kb):

As you can see, there is a final bundle size difference. By not using barrel file, it's smaller.

Circular dependency is another problem with barrel files.

Enjoying it? If so, don't forget to give a ❤️_ and follow me to keep updated. Then, I'll continue creating more content like this_

What is the Barrel files cost for the unit tests?

The barrel file on unit tests is even worse, once unit tests engines such as Vitest and Jest don't care about bundle optimization as Vite and Webpack. Let's see by creating two helpers that only use HEY.

// ./helper.ts
import { HEY } from './barrelFiles';
export const helper = () => {
  console.log(HEY);
};

// ./helper2.ts
import { HEY } from './barrelFiles';
export const helper2 = () => {
  console.log(HEY);
};

And now import them into the test files

// ./helper.epec.ts
import { describe, it } from 'vitest';
import { helper } from './helper';

describe('helper', () => {
  it('Should only use HEY', () => {
    helper();
  });
});

// ./helper2.epec.ts
import { describe, it } from 'vitest';
import { helper2 } from './helper2';

describe('helper2', () => {
  it('Should only use HEY', () => {
    helper2();
  });
});

using barrel file on tests time: 2.61s

As you can see, there is a bunch of not-used console.log, and that gonna happen for EACH test file on the project that uses the barrel file or even use a file that uses the barrel file. Can you imagine the performance impact of it? Well... terrible.

Now, removing the barrel files

not using barrel file on tests time: 1.32s

Buy me a coffee ☕. Hope I have helped you somehow. 🤗

BONUS (change import statements automatically)

[UPDATE Jul, 4th of 2024]:
Check out this script to change import statements automatically. It will help you to remove barrel files.

[UPDATE Jul, 17th of 2024]:
And also, check out the Eslint plugin eslint-plugin-no-barrel-files to avoid, well, barrel files.

[UPDATE Mar, 18th of 2025]: Do you prefer a CLI? Check this amazing CLI powered by Nergie

Conclusion

[UPDATE Mar, 23th of 2024]:
In this article, you learned more about the barrel file pattern and its impact on final front-end applications.

As I have said before: creating patterns that avoid team-mattes (and you) doing things wrong is the best thing you can do as a developer. That is valid to barrel files once not using them:

Reducing the final bundle and avoiding importing stuff are not used;
Improve the unit test performance;

Expensive.

See my other articles

Loading chunks on demand - beyond the router (part 1)

Tássio — Fri, 11 Aug 2023 00:04:18 +0000

It's time to control when your application requests the chunks of your page and optimize the loading.

Let's look at how to split up the chunks and load them at the right time. I'll show it with a personal project. The stack is as follows:

React (SPA);
Vite;

The same is applicable (changing the syntax, obviously) to any other JS frameworks and bundler tool, consult the doc to know how.

NOTE: This post is split into two parts. Read part 2 here

What are chunks at development word?

Usually, front-end developers have contact with .ts, .vue, and .tsx files, but browsers don't understand them. To do so, it needs to convert those files into .js files - and they can even be optimized, typically by using a build command.

Even though all development files can be converted into a single .js file, it's not recommended because of the performance impact. Ideally, those files a converted into multiple .js files (chunks) to take the ability to load the files at the moment they are required - thinking on user navigation.

So, chunks are .js files that, together, define a whole front-end system, in a nutshell.

React.lazy

React.lazy is a React tool to load js code on demand, optimizing application performance. The idea is to avoid downloading, parsing, and compiling js code before it's required. Ideally, the main mindset it's to define the load order so your application looks faster.

It's usually used for lazy loading routes on SPA applications, but I'm gonna show you how to use it in other scenarios such as using data from an API.

Current project bundle

To start, let's see what the project looks like:

It's a simple view that gets my Dev.to articles and renders a card for each item from the API (https://dev.to/api/articles?username=tassiofront).
Now, let's see what the load page looks like in the Network tab:

It's possible to see that the article HTTP request is called after all JS files are downloaded, parsed, and compiled. But, does it really need all that JS content before calling the API? Well, it just needs the card's chunk when there is data from the API, right? So, Why not load it after the GET has finished?

Note: I have reduced the whole code to teaching purposes, but at the bottom, you can find the commit and the full source code. Read the comments to understand.

// READ: importing lazy and Suspense APIs
import { useEffect, useState, Suspense, lazy } from 'react';

import BaseScreen from '@/components/BaseScreen/BaseScreen';
import Section from '@/components/Section/Section';
import { texts } from './enums';
import { getOwnerDevArticlesByUserName } from '@/services/devPublicApi.service';
import { IArticle } from '@/models/Article';
import RouterFallback from '@/components/RouterFallback/RouterFallback';

// READ: Creating a function to load the ArticlesContent component later. This is the component that renders all card articles
const ArticlesContent = lazy(
  async () => await import('./components/Content/Content')
);

const Article = (): JSX.Element => {
  const [articles, setArticles] = useState<IArticle[]>([]);
  const getUserInfo = async (): Promise<void> => {
    const response = await getOwnerDevArticlesByUserName();
    setArticles(response.data);
  };
  useEffect(() => {
    void getUserInfo();
  }, []);

  return (
    <BaseScreen heading={texts.heading} description={texts.description}>
      <Section>
        <>
          {articles?.length > 0 && (
            //READ: Avoid downloading, parsing, and compiling the card chunk before it's required
            <Suspense fallback={<RouterFallback />}>
              <ArticlesContent articles={articles} error="something went wrong" />
            </Suspense>
          )}
        </>
      </Section>
    </BaseScreen>
  );
};

export default Article;

With that simple changes, let's see the difference in the Network tab:

Do you see?

Now there is one more chunk (Content.hash.js) which is loaded after articles GET. Wait, one more chunk?! Isn't it bad? NO!

There is no more code now than before, but now we split up our code removing what is not required before it gets all article data, creating a logic order, and optimizing the load page.

Conclusion

In this article, you saw a bit more about chunks, and how to split them using React.lazy. Creating a logic order and optimizing the load page.

This is something interesting to keep in mind when creating new stuff. It's not just creating, but how it's created also matters.

See my other articles

What's next

Read part 2 here

Splitting vendor chunk with Vite and loading them async

Tássio — Mon, 07 Aug 2023 21:15:44 +0000

How have your website chunks been? Does it need a diet?

Let's take a look at how to split the vendor chunk and reduce its size. Allowing the browsers to loading smaller chunks and loading them async. I'll use a personal project to show it. The stack is as follows:

The same applies to any other js frameworks with Vite. It might applicable with Webpack too, consult the doc to know how.

See my other articles

What are chunks at development word?

Even though all development files can be converted into a single .js file, it's not recommended because of the performance impact. Ideally, those files a converted into multiple .js files (chunks) to take the ability to loading the files at the moment they are required - thinking on user navigation.

So, chunks are .js files that, together, define a whole front-end system, in a nutshell.

Current project bundle

To start, let's see how the project looks like:

As you can see, there are some js files in the project. let's focus on the index.hash.js.

Usually, tools such as Vite and Wepack create two main chunk files: index.hash.js and vendor.hash.js:

index: there are crucial application codes, such as App.tsx code;
vendor: All production dependencies (package.json > dependencies);

Wait. Why isn't the vendor chunk at the gif? Vite has removed this behavior since the 2.9 version. Now, by default, the index also has the production dependencies code.

By using Rollup Plugin Visualizer, which gives us an interactive graph of the project bundle, it's easier to see:

As you can see, there is a huge index chunk.

The first thing we can do is to split core content from third-party content, which allows the browser to download both files async by adding the modulepreload attribute.

But before move on, see the current index size (255.35 kb):

Split index chunk into two chunks and load them async

Even though Vite doesn't split them by default, it provides a plugin to do it for you:



import { splitVendorChunkPlugin } from 'vite';

export default defineConfig({
  plugins: [
    react(),
    splitVendorChunkPlugin()
]})

Vite does the rest for you.

Vendor size: 239.95kb
Index size: 15.90kb

Well, it's possible to see how third-party packages impact the bundle of this project.

Enjoying it? If so, don't forget to give a ❤️_ and follow me to keep updated. Then, I'll continue creating more content like this_

Split vendor chunk into more chunks

As we figured out who is the villain, let's try to split the vendor chunk into smaller chunks.

To do so, we gonna use the manualChunk function, provided by Rollup. But before it, we must decide who we'll remove from the main vendor chunk(?) and that's the trick question... looking into our bundle again, we find some huge (comparing with other) packages, like react-dom, but to this article, I will create two other chunks from vendor chunk:

@open-ish
@react-router

Why? Well, when we have a vendor chunk, it might have dependencies that must be loaded in the right order, as some of them might use others, otherwise, your application might not work. This is the hardest part of creating chunks manually: knowing who must be in the same chunk and it depends on the application you have been working on. For my project, I know that those dependencies must be in the same chunk: 'react-router-dom', '@remix-run', and 'react-router'.

So let's see the code to split them:



import { splitVendorChunkPlugin } from 'vite';

export default defineConfig({
  plugins: [
    react(),
    splitVendorChunkPlugin()
],
 build: {
    rollupOptions: {
      output: {
        manualChunks(id: string) {
          // creating a chunk to @open-ish deps. Reducing the vendor chunk size
          if (id.includes('@open-ish') || id.includes('tslib')) {
            return '@open-ish';
          }
          // creating a chunk to react routes deps. Reducing the vendor chunk size
          if (
            id.includes('react-router-dom') ||
            id.includes('@remix-run') ||
            id.includes('react-router')
          ) {
            return '@react-router';
          }
        },
      },
    },
  },
})

With this code, Rollup will create two new chunks:

And now, comparing the vendor chunk size:

Vendor size: 211.94kb

As we can see, we reduce the biggest chunk from 255.35kb to 211.94kb (~18%). That might not sound too much, but it is just the beginning of splitting out the chunks and creating smaller ones and even given the possibility of loading them async to the browser.

See now how our application loads (focus on the waterfall):

They start to load at the same time, did you see?

Buy me a coffee ☕. Hope I have helped you somehow. 🤗

Conclusion

In this article, you saw a bit more about chunks, and how to split them and load them async using Vite/Rollup.

Even though the code itself is simple (thanks to Vite/Rollup), the hardest is to identify which dependencies must be in the same chunk.

I might create a second part of this content splitting the vendor chunk more, later.

See my other articles

Criando multi layouts em SPA`s Vue (2.x ou 3.x). 👨‍🎨👨🏾‍🎨

Tássio — Sat, 03 Oct 2020 14:50:44 +0000

Motivação (SPA feita em Vue 3)

Quando trabalhamos em SPA's ( e em aplicações Web no geral), podemos nos deparar em páginas (views) que tem diferentes estruturas (layouts). Em certos casos, as diferenças são tão grandes que chega ser inviável (isso quando possível) contornar a situação via medias querys, por exemplo.

OBS: estou considerando que já tenha algum conhecimento prévio em Vue:

Veja só:

Imagine que sua aplicação tenhas páginas com layouts tão diferentes, como possibilitar isso de maneira legível? Tenha em mente que o próprio conteúdo do header e alt header, por exemplo, podem ser totalmente diferentes entre os layouts. Além da possibilidade de diferença semântica.
Vou propor uma alternativa, neste post, para SPA feita em Vue.

Case Nutris - link do repo

Nutris é uma PWA para cálculo de dietas parenterais. Sua primeira versão está no ar desde 2019 e agora está sendo refatorada, deixando código aberto no repo da open-ish.

Nossa home deslogada terá header e footer com conteúdos totalmente diferentes e não terá um menu de navegação. Já quando logado, além da mudança dos conteúdos, teremos um menu de navegação. Por fins didáticos, usarei exemplos simples de componentes para diferenciarmos os layouts e views.

Estrututa do projeto

Vamos criar dois layouts: default e alt (alternativo). Cada layout terá suas rotas e views respectivas (ou seja, a views dentro de default, são do layout default), referencias pelo próprio nome.

Então vamos lá, na raiz do projeto, teremos uma nova pasta de nome layouts.

Antes de vermos a rotas, vamos entender como ficarão nossos componentes. Lembrando que esse sistema de rotas usa vue-router

Mãos na massa

Vamos fazer nosso App.vue ser flexível usando a tag router-view sozinha, ao invés de inserirmos tags padrões (ex: header e footer) como comumente fazemos aqui.

App.vue

<template>
  <router-view />  <!-- Components will render by router -->
</template>

Layout - Default 👨🏾‍🎨

src/layouts/defautt/Default.vue

<template>
  <header>
    Default Header
  </header>
  <main class="default">
     <!-- Views'll render here -->
    <router-view /> 
  </main>
  <footer>Default footer</footer>
</template>

Veja que dentro do layout, teremos um router-view que ficará responsável por renderizar os componentes de acordo com a pagina.

Views - Default

Vamos criar as views que serão renderizadas dentro dos layouts. Lembrando que as que estão na pasta default, fazem parte do layout default; e as que estão na pasta alt, fazem parte do layout alt.

src/views/default/Home.vue

<template>
  <h2>Home page</h2>
</template>

src/views/default/About.vue

<template>
  <h2>About page</h2>
</template>

Show!! Criado nossos componentes de exemplo para o layout default, vamos criar nossas rotas. Por fins didáticos, vou manter tudo no mesmo arquivo, mas em casos reais uso a estrutura que comentei a cima.

Rotas - Default

src/router/index.js 👀

// import components (layouts and views)
import DefaultLayout from '@/layouts/default/Default.vue'
import Home from '@/views/Home.vue'
import About from '@/views/About.vue'

// Lets create default route, to default layout
const defaultRoute = {
  path: '/',
  component: DefaultLayout,  
  children: [
   path: 'home',
   component: Home, // it'll render at default layout
   path: 'about',
   component: About // it'll render at default layout
  ]
}

const routes = [defaultRoute]

const router = createRouter({
  history: createWebHistory(process.env.BASE_URL),
  routes,
})

export default router

Rodando o projeto, na rota '/' teremos (PS: coloquei alguns estilos pra ficar mais bonitinho 😅🎨):

e na '/about':

Beleza, com isso, todas as nossas rotas terão a mesma estrutura (layout). Então vamos possibilitar que tenhamos um layout alternativo.

Layout - Alt 👨‍🎨

src/layouts/alt/Alt.vue

<template>
  <header>
    Alt Header
  </header>
  <section class="alt">
    <!-- Views'll render here -->
    <router-view /> 
  </section>
  <footer>Alt footer</footer>
</template>

Veja que no layout alt, temos a tag section ao invés da main. 😁😁

Views - Alt

src/views/alt/Alt.vue

<template>
  <h2>Alt page</h2>
</template>

src/views/alt/SomeAlt.vue

<template>
  <h2>SomeAlt page</h2>
</template>

Rotas

src/router/index.js 👀

// import components (layouts and views)
import DefaultLayout from '@/layouts/default/Default.vue'
import Home from '@/views/Home.vue'
import About from '@/views/About.vue'

// Alt layout and views
import AltLayout from '@/layouts/alt/Alt.vue'
import Alt from '@/views/alt/Alt.vue'
import SomeAlt from '@/views/alt/SomeAlt.vue'

// Lets create default route, to default layout
const defaultRoute = {
  path: '/',
  component: DefaultLayout,  
  children: [
   path: 'home',
   component: Home, // it'll render at default layout
   path: 'about',
   component: About // it'll render at default layout
  ]
}

// Lets create alt route, to alt layout
const altRoute = {
  path: '/alt',
  component: AltLayout,  
  children: [
   path: '',
   component: Alt, // it'll render at alt layout
   path: 'some-alt',
   component: SomeAlt // it'll render at alt layout
  ]
}

const routes = [defaultRoute, altRoute]

const router = createRouter({
  history: createWebHistory(process.env.BASE_URL),
  routes,
})

export default router

Veja como ficou a '/alt':

E a '/some-alt':

Voilà!!

See my other articles