DEV Community: Diego Souza

Easy way to streaming image S3 AWS

Diego Souza — Wed, 19 Feb 2025 13:19:23 +0000

Stream de Arquivo PDF ou Imagem S3 - AWS

Diego Souza ・ Jan 10

Stream de Arquivo PDF ou Imagem S3 - AWS

Diego Souza — Fri, 10 Jan 2025 17:39:33 +0000

Objetivo

Esse conteúdo tem como objetivo mostrar de forma simples uma das maneiras de fazermos streaming de arquivos PDF ou imagens direto de um Bucket S3, da AWS.

Como premissa, a aplicação deve ser em Node.JS.

Instalando SDK AWS

npm install @aws-sdk/client-s3

Configurando Client

Basicamente, o objeto de configuração do cliente S3 precisa receber a região e as credenciais - que são adquiridas no IAM da AWS. Talvez, dependendo do contexto da sua aplicação é necessário usar um proxy. Sobre isso, no final desse artigo tem um exemplo de como configurar um proxy.

const awsConfig = {
   region: 'us-east-1',
   credentials: {
      accessKeyId: '',
      secretAccessKey: '',
   }
};

s3Client = new S3Client(awsConfig);

Buscando Objeto no S3

Com o cliente configurado, agora é possível buscar um arquivo no S3. Para isso, é necessário um objeto informando o nome do Bucket e o ID do arquivo. Geralmente esse ID é o nome do arquivo. Então, cuidado com acentuações e caracteres especiais ao fazer o upload de arquivos.

Para buscar o arquivo, usamos o getObjectCommand, conforme abaixo.

const object = {
   Bucket: 'bucket-name',
   Key: 'file-id'
};

const getObjectCommand = new GetObjectCommand(object);

return s3Client.send(getObjectCommand);

Retornando o Arquivo para o Frontend

Para retornar o arquivo para o navegador usando seu tipo correto, podemos fazer uso do Content-Type que é disponibilizado pelo response no caso de estar usando o Express.

streamFile = async (request, response, next) => {
   const fileStream = new GetStreamFileService();
   const responseStream = await fileStream.execute({ fileId, bucket });

   response.setHeader('Content-Type', responseStream.ContentType);

   return responseStream.Body.pipe(response);
}

Note que no return é usada a função pipe, que é do próprio SDK da AWS, que existe dentro do Body. Essa função tem o recurso de stream dentro dela. Então, passamos apenas o response do Express como parâmetro.

Feito isso, provavelmente você terá uma rota configurada para acessar esse serviço. Geralmente, fazemos assim:

<img src="/routes/files/id-do-arquivo" alt="Stream de Imagem do S3" />

Se for um arquivo PDF, você pode abrir direto no browser, ou object usando o link.

<object data="/routes/files/id-do-arquivo" type="application/pdf">
   Não foi possível fazer o streaming desse arquivo.
</object>

Proxy

Baseada na minha experiência, tive dificuldades em fazer streaming de arquivos certa vez. Estava configurado corretamente, mas sempre retornava algum erro. Buscando pela engenharia dos servidores, entendi que era necessário usar um proxy para acessar o S3.

Na própria documentação do SDK do S3 encontrei uma solução, usando as bibliotecas hpagent e @aws-sdk/node-http-handler. Depois, usamos o proxy dentro do objeto de configuração do S3.

const agent = new HttpsProxyAgent({ proxy: '' });
const requestHandler = new NodeHttpHandler({
   httpAgent: agent,
   httpsAgent: agent,
});

const awsConfig = {
   region: 'us-east-1',
   requestHandler,
   credentials: {
      accessKeyId: '',
      secretAccessKey: '',
   }
};

Espero que esse artigo te ajude em algum momento de sua carreira.

HOC Pattern - React

Diego Souza — Fri, 07 Jun 2024 14:17:36 +0000

No segundo artigo desta série de como fazer uso de design patterns em projetos, especificamente usando React, vamos considerar - um dos meus preferidos - o pattern High Order Component (HOC).

Em poucas palavras, o HOC é uma técnica em que uma função recebe um componente em seu argumento e esta função contém uma lógica que afeta o componente passado por parâmetro, para então renderizá-lo.

O HOC nos permite encapsular uma mesma lógica a ser utilizada em múltiplos componentes sem que precisássemos replicar a lógica em todos eles. Pode ser uma lógica que envolve estilos, permissões, visibilidade de micro-componentes dentro de um componente, além de outros casos de uso.

Show me the code

Imagine que você tenha o seguinte componente:

import React from "react";

export const Me = () => {
  const isLoggedIn = useAuth();

  async function handleGetMe() {
    const response = await fetch('/profile');
    const data = await response.json();

    return data;
  }

  if (!isLoggedIn) {
    return (
       <div>
          Você precisa estar logado para ver essas informações.
       </div>
    );
  }

  const profile = handleGetMe();

  return (
    <div>
       <h2>{profile.name}</h2>
       <p>{profile.job}</p>
    </div>
  );
};

Como podemos ver acima, esse componente possui uma lógica de permissionamento. Se o usuário estiver logado, é possível ver os seus dados, mas se não estiver, recebe uma mensagem.

No entanto, temos duas observações a fazer:

Não é tão interessante ter uma lógica assim dentro do componente que tem como objetivo realmente mostrar algo na tela;
Pode ser que essa lógica precise ser usada em outros componentes e nesse formato teria que replicar a lógica nos outros componentes também.

Com certeza há várias formas de construir uma solução para isso, de forma que pudéssemos reutilizar a lógica em múltiplos componentes sem precisar repetir o contexto.

O HOC é uma dessas soluções. Veja um exemplo de criação e uso desse design pattern.

export default function renderIfAuthenticated(Component: JSX.ElementType) {
   return (props) => {
      const isLoggedIn = useAuth();

      if (!isLoggedIn) {
         return (
            <div>
               Você precisa estar logado para ver essas informações.
            </div>
         );
      }

      return <Component {...props} />;
   }
}

Agora, nós conseguimos centralizar a lógica dentro de uma função HOC. Em outras palavras, transferimos a responsabilidade para uma única função. Recebemos o componente por parâmetro e o renderizamos apenas se a condição que definimos for verdadeira, nesse caso. E para utilizar podemos fazer assim:

import { renderIfAuthenticated } from "../hocs/renderIfAuthenticated";

export function Me() {
   async function handleGetMe() {
      const response = await fetch('/profile');
      const data = await response.json();

      return data;
   }

   const profile = handleGetMe();

   return (
      <div>
         <h2>{profile.name}</h2>
         <p>{profile.job}</p>
      </div>
   );
}

const MeRenderWithAuth = renderIfAuthenticated(Me);
export default renderIfAuthenticated;

Note que o componente em si, se mantém o mesmo. A linha de código que faz o encapsulamento no HOC é esta:

const MeRenderWithAuth = renderIfAuthenticated(Me);

Assim, podemos reutilizar essa lógica em outros componentes que vão fazer uso da mesma lógica de permissionamento.

Vamos ver outro caso de uso. Por exemplo, ao aplicar os mesmos estilos em alguns componentes e extender estilos que serão diferentes para cada um.

export function renderWithStyles(Component: JSX.Element) {
  return (props) => {
    const style = {
      backgroundColor: "#0B1215",
      color: "#F5F5F5",
      ...props.style,
    };

    return <Component {...props} style={style} />;
  };
}

Aplicando o HOC em múltiplos componentes:

Button

import { renderWithStyles } from "../hocs/renderWithStyles";

export const Button = (props) => (
  <button style={{ fontSize: "20px", ...props.style }}>Enviar</button>
);

const StyledButton = renderWithStyles(Button);
export default StyledButton;

Cardboard

import { renderWithStyles } from "../hocs/renderWithStyles";

export const Cardboard = (props) => (
  <div style={{ fontSize: "20px", fontFamily: "Roboto", ...props.style }}>Enviar</div>
);

const StyledCardboard = renderWithStyles(Cardboard);
export default StyledCardboard;

Basicamento, o que fizemos acima é o que é feito na biblioteca de estilos CSS-In-JS muito conhecida chamada Styled Components. Veja o exemplo abaixo tirado da documentação:

const Button = styled.button`
  color: #BF4F74;
  font-size: 1em;
  margin: 1em;
  padding: 0.25em 1em;
  border: 2px solid #BF4F74;
  border-radius: 3px;
`;

// Aplicação do HOC
const TomatoButton = styled(Button)`
  color: tomato;
  border-color: tomato;
`;

O TomatoButton vai herdar os estilos do Button e acrescentar ou substituir propriedades exclusivas para ele.

Considerações finais

Reusabilidade - Os HOC's nos permitem encapsular funcionalidades que são compartilhadas em vários componentes, promovendo o reuso do código;

Separation of Concerns (SOC) - Ajudam a manter a separação de responsabilidades da aplicação, assim os componentes podem focar no objetivo de uso deles;

Abstração de Código - Como os HOC's abstraem a lógica em comum de um ou mais componentes, fica mais canalizado e fácil de entender e dar manutenção;

Composição - Podemos combinar vários HOC's para compor uma funcionalidade complexa dentro dos componentes. Um exemplo de uso de algo assim, mas mais antigo é do MapStateToProps e do MapDispatchToProps do React-Redux:

export default connect(mapStateToProps, mapDispatchToProps)(AppWrapper(MyComponent))

Portanto, fazer uso dos HOC's tornarão sua aplicação mais fácil de manter e entender, por promover um código limpor e reusável. Assim, suas aplicações React serão mais eficientes.

Mas como todos os padrões de projeto, é preciso pensar no caso de uso, na necessidade e até mesmo na complexidade do projeto para decidir se seria interessante o uso de HOC's.

Container & Presentational Pattern - React

Diego Souza — Tue, 20 Jun 2023 15:00:33 +0000

Os padrões de design ou design patterns tem como objetivo trazer ao projeto organização, legibilidade e como o próprio nome diz, padrões.

Esse é o primeiro artigo de uma série de como fazer uso de design patterns em projetos, especificamente usando React. E para começar vamos considerar o pattern que chamamos de Container/Presentational Pattern.

Tanto o container quanto o presentational são componentes, mas a forma com que eles trabalham são diferentes e tem como principal objetivo separar as responsabilidades. Com esse pattern nós podemos separar a responsabilidade da visualização da responsabilidade da lógica da aplicação.

Caso ainda essa explicação esteja nebulosa em sua mente, vamos as considerações e exemplos.

Container

São componentes que em sua responsabilidade está em como os dados são apresentados na interface. A principal função dos container components é passar os dados para os presentational components.

Princípios

De modo geral os container components renderizam apenas os presentational components que se relacionam com os dados que precisam ser apresentados por aquele componente;
Além disso, geralmente também esses componentes não recebem estilos, visto que apenas passam os dados para os componentes que realmente farão a renderização da interface - os presentational components;
O foco desse componente é no comportamento e funcionalidade da aplicação, como os métodos e lógicas;
O gerenciamento de estados fica concentrado nesse componente, assim como também o fluxo de dados. Caso precise usar hooks, variáveis e método de contexto esse é o componente que irá fazer isso;
Facilidade em usar e entender as dependências do componente, como outras bibliotecas.

Presentational

São componentes que em sua responsabilidade está em *o que * mostrar na interface. A principal função dos presentational components é mostrar os dados que são recebidos.

Princípios

Os dados são passados do container para os presentational por meio de props;
Esses dados não são modificados no presentational, apenas exibidos. Se precisar alterar os dados faça isso dentro do container components;
É um stateless component. Isto é, ele não gerencia nenhum estado, ou se gerenciar, que seja algo muito pontual;
Recebe os dados exclusivamente por meio de props do container.

Essa é uma imagem que representa esse design pattern, com um mínimo de lógica - um fetch de dados que é feito dentro do container e passado por props para dentro do presentational.

Show me the code

Container



import { useState, useEffect } from 'react';
import { PresentationalComponent } from './PresentationalComponent';

const ContainerComponent = () => {
  const [data, setData] = useState([]);

  function handleFetch() {
    fetch("https://randomuser.me/api")
      .then((response) => response.json())
      .then((data) => setData(data));
  }

  useEffect(() => {
    handleFetch();
  }, []);

  return (
      <PresentationalComponent 
         {...data} 
         handleFetch={handleFetch} 
      />
   );
};

Como mostra o código acima, a lógica, métodos e estados ficam dentro do container component. E os dados que precisam ser apresentados em tela se passa por props para dentro do presentational component, assim como também os métodos.

Presentational



const PresentationalComponent = ({ 
   name, 
   email, 
   location, 
   handleFetch 
}) => {
  return (
    <Profile>
      <Info>{name.first}</Info>
      <Info>{email}</Info>
      <Info>
        {location.city}, {location.state}
      </Info>
      <Button onClick={handleFetch}>Buscar</Button>
    </Profile>
  );
};

E como mostra o código acima, o objetivo do componente é apenas exibir os dados e se possível praticamente mais nada deve ser de sua responsabilidade.



.
├── ...
├── components
    ├── ExampleComponent
        ├── container
            ├── index.tsx
        ├── presentational
            ├── index.tsx
        index.tsx

Para extrair o máximo de vantagens desse design pattern procure utilizar a convenção de nomenclatura de pastas e de arquivos em todo o projeto. Fazer assim vai facilitar o entendimento da aplicação e ajudará na manutenção dos componentes.

Note que há um arquivo index na raiz da pasta do componente. Esse arquivo tem como objetivo apenas exportar o container. É esse arquivo index que podemos usar para chamar o container component na aplicação.



export { ContainerComponent as Container } from './container';

Talvez seja redudante e a comunidade reclama da quantidade de arquivos que se cria nesse design pattern. Pode ser que esse seja um dos ônus de usar esse pattern. Mas particularmente, não me importo com isso.

Acredito que essa convenção é mais para o desenvolvedor se localizar dentro do mundo das pastas de um projeto enorme por meio da IDE.

O ideal é nunca exportar o presentational component em qualquer arquivo que não seja o container component no qual ele está relacionado.

Além disso, poderá criar testes unitários de forma mais fácil para os dois tipos de componentes. Para isso mantenha o componente de apresentação o mais simples possível focando na renderização de propriedades e chamadas de métodos. Assim, o arquivo vai ficar mais limpo e legível.

Pode ser que com o tempo o container comece a ficar grande ou complexo. Antes disso acontecer, estude utilizar hooks e contexto para fazer a busca (fetch) de dados da API ou outro gerenciamento de estado que possa ser utilizado em toda a aplicação.

Dessa forma também, o container ficará mais limpo e legível.

Exemplo com hooks

Hooks



import { useState, useEffect } from 'react';

const useFetchUser = () => {
  const [data, setData] = useState([]);

  function handleFetch() {
    fetch("https://randomuser.me/api")
      .then((response) => response.json())
      .then((data) => setData(data));
  }

  useEffect(() => {
    handleFetch();
  }, []);

  return {
    handleFetch,
    data
  }
};

Container



import useFetchUser from '@hooks/useFetchUser';
import { 
   PresentationalComponent 
} from './PresentationalComponent';

const ContainerComponent = () => {
  const { data, handleFetch } = useFetchUser();

  return (
      <PresentationalComponent 
         {...data} 
         handleFetch={handleFetch} 
      />
   );
};

O arquivo ficou menor e o presentational component permanece da mesma forma.

Minhas considerações

Esse design pattern pode ser substituído por muitos outros, diria eu, até melhores e mais fáceis de trabalhar visando os mesmos princípios explicados e mostrados aqui. Porém, esse artigo foi criado não com o objetivo de incentivar o uso desse pattern, mas por razões acadêmicas e seculares.

Pode ser que você encontre um projeto assim em seu trabalho e provavelmente terá que seguir esses padrões, visto custar tempo, dinheiro e até mesmo experimentar riscos para mudar esse padrão.

Em resumo, não aplique esse design pattern em todo projeto que começar de maneira deliberada. Avalie bem a necessidade, motivação e conhecimentos técnicos seus e do time antes de decidir qual arquitetura usar no projeto.

Pode ser que você encontre artigos em que ao invés dos nomes container e presentational, sejam smart e dumbs, mas como até diz no arquivo de referência do Dan, esses nomes não explicam nada.

Referências

MSW - Mock Service Worker - Escopo

Diego Souza — Tue, 20 Sep 2022 13:17:01 +0000

No artigo anterior vimos um exemplo de como podemos usar o MSW para interceptar uma requisição HTTP e retornar informações fictícias para usar em testes unitários. Quando fazemos isso é importante termos em mente que a requisição real não é executada, pois ela é interceptada pelo msw.

Neste artigo, vamos ver um exemplo de como deixar as funções do msw em um escopo maior para que os testes - it - levem em conta o mock. Assim, evitamos de a cada teste - it - inserir o código novamente, isto é, o DRY - Don't Repeat Yourself.

Show me the code

Imaginem o seguinte cenário: precisamos criar 2 testes para verificarmos se os dados que estão vindo da API estão corretos e o que fazemos com estes dados estão de acordo com a regra de negócio que definimos. Então, concluímos que a resposta da API deve ser sempre de sucesso, ou seja, HTTP Status Code 2xx - 200, 201, 204...

// getUserInfoGithub.js
import axios from 'axios';

export const getUserInfoGithub = async ({ username }) => {
  const { data } = await axios.get(
     `https://api.github.com/users/${username}`
  );

   return {
      ...data,
      hasTwitter: Boolean(data.twitter_username),
      hasBlog: Boolean(data.blog),
   };
};

const { setupServer } = require('msw/node');
const { rest } = require('msw');

const getUserInfoGithub = require('./getUserInfoGithub');

const endpoint = "https://api.github.com/users/:username";

const createServer = () => 
   setupServer(
      rest.get(endpoint, (request, response, ctx) =>
         response(
            ctx.status(200),
            ctx.json({
               id: 12345678,
               twitter_username: '@TwitterUser',
               blog: 'https://gist.github.com/username',
            })
         )
      )
   );

beforeAll(() => createServer.listen());
afterEach(() => createServer.resetHandlers());
afterAll(() => createServer.close());

describe('Testing User Service', () => {
   it('should return user info twitter username', async () => {
      const response = await getUserInfoGithub('MockUser');

      expect(response.hasTwitter).toBeTruthy();
   });

   it('should return user info link blog', async () => {
      const response = await getUserInfoGithub('MockUser');

      expect(response.hasBlog).toBeTruthy();
   });
});

Sobre o código acima, vamos as explicações:

A diferença desse código para o código do artigo anterior é o use do beforeAll do Jest. Traduzindo, o beforeAll vai executar o código dentro dele antes de todos os testes rodarem. E o código que será executado é a função createServer.

Então, antes do primeiro it executar, o servidor mock será executado e ficará ouvindo - listen - as requisições que serão feitas realmente.

O afterEach significa que depois de cada teste - it - o msw vai limpar ou resetar os manipuladores de requisição para que não afete outros testes unitários do projeto.

E o afterAll determina o que vai acontecer depois que todos os testes forem executados, nesse caso irá limpar todas os mocks que foram abertos e fechar a conexão com o servidor fictício.

Pontos de Atenção

Ao fazermos isso, todos os testes de dentro desse arquivo que na realidade farão uma requisição GET para esse endpoint vão obedecer esse mock. Isso é importante saber, porquê se em algum momento você precisar testar uma resposta HTTP Status Code diferente de 2XX, não vai dar certo. Nesse caso você precisará criar o escopo de outra forma. Segue abaixo as diferenças:

Note que deixamos a variável createServer flexível para ser usada em outros lugares e invocar outros métodos do setupServer. Assim, podemos criar outro teste para testarmos uma resposta diferente de 200 - OK.

it('should return user info link blog', async () => {
   createServer.use(
      rest.get(endpoint, (request, response, ctx) =>
         response(ctx.status(400))
      )
   );

   await expect(getUserInfoGithub('MockUser')).rejects.toThrow();
});

Nesse cenário usamos a função use do setupServer onde conseguimos encadear outro mock, agora com uma resposta diferente, o HTTP Status Code 400 - BAD REQUEST.

E assim conseguimos testar o erro usando o await antes do expect, por se tratar de uma Promise no retorno da função. E o expect estende o método rejects - que lembra o then - para recuperar o retorno.

Diante disso temos os resultados:

Outro ponto de atenção é que esse código que fizemos vai funcionar dentro do escopo desse arquivo de teste unitário. Mas você pode como que escalar ainda mais o escopo dele. Geralmente no projeto, tem um arquivo chamado jest.setup.js ou setupTests.js.

Dentro dele, você pode criar um servidor mock e colocar as requisições que você deseja interceptar para todos os arquivos de testes, como abaixo:

const { setupServer } = require('msw/node');
const { rest } = require('msw');

const createServer = 
   setupServer(
      rest.get(endpoint, (req, res, ctx) => ()),
      rest.post(endpoint, (req, res, ctx) => ()),
      rest.put(endpoint, (req, res, ctx) => ()),
      rest.delete(endpoint, (req, res, ctx) => ()),
   );

beforeAll(() => createServer.listen())
afterEach(() => createServer.resetHandlers())
afterAll(() => createServer.close())

E depois aplicar essa configuração no arquivo jest.config.js:

// jest.config.js
module.exports = {
   setupFilesAfterEnv: ['./jest.setup.js'],
}

Referências

Documentação do MSW

MSW - Mock Service Worker - Introdução e Teste Unitário

Diego Souza — Thu, 15 Sep 2022 12:43:59 +0000

Onde usar o MSW?

Essa biblioteca pode ser usada em pelo menos três circunstâncias: testes, desenvolvimento e debugging. Mas independente da circunstância o objetivo do MSW é interceptar requisições que são feitas pela aplicação para alguma determinada API.

Este artigo se concentrará especificamente nos Testes. Nos próximos artigos vou trazer como configurar o MSW para criar uma API Fake ao desenvolvermos uma aplicação em React.

Testes

Com o MSW nós podemos criar um mock, isto é, simular um comportamento de uma classe ou objeto real com dados não-reais ou fictícios, por exemplo, em testes unitários.

Neste artigo, o foco é apenas em um teste unitário com NodeJS + Jest. No próximo artigo vou mostrar como reutilizar o mock em vários testes ao mesmo tempo.

Exemplo em NodeJS com Jest

// getUserInfoGithub.js
import axios from 'axios';

export const getUserInfoGithub = async ({ username }) => {
  // Desestruturando o `data` do retorno da chamada
  const { data } = await axios.get(
     `https://api.github.com/users/${username}`
  );

  return data;
};

// getUserInfoGithub.spec.js

import { setupServer } from 'msw/node';
import { rest } from 'msw';

import getUserInfoGithub from './getUserInfoGithub';

const endpoint = 'https://api.github.com/user/:username';
const httpStatusCode = 200;

it("should return user info of the github api", async () => {
  // Criando mock de interceptação da requisição
  setupServer(
    rest.get(endpoint, (request, response, ctx) => {
      const { username } = request.params;

      return response(
        ctx.status(httpStatusCode),
        ctx.json({
           id: 123456789,
           login: username,
           name: "John Doe",
           location: "Brasil",
        });
      );
    })
  ).listen();

  const response = await getUserInfoGithub('MOCK');
  const expected = {
     id: 123456789,
     name: "John Doe",
     location: "Brasil",
  };

  expect(response).toMatchObject(expected);
});

Sobre o código acima, vamos as explicações:

Invocamos a função setupServer que é responsável por criar um listener, ou seja, um evento que tem como objetivo ouvir um comportamento real. Nesse caso, o comportamento é uma requisição GET para a API do Github. É por isso que ao final da função, invocamos a função listen() - não esqueçam de colocá-la.

Dentro da função é declarado um rest.get que será disparada no momento que na função getUserInfoGithub for feita uma requisição GET. Nesse caso estou utilizando o axios, mas pode ser qualquer biblioteca para fazer requisições HTTP.

Dentro da função rest.get temos três variáveis importantes que descrevem a requisição. No entanto, não queremos apenas simular a requisição, mas também a resposta da requisição. Pensando nisso, leia as observações abaixo:

O primeiro parâmetro da função rest.get recebe um endpoint. Coloque nesse parâmetro, o endpoint em que a requisição será feita de verdade.
O segundo parâmetro da função rest.get recebe uma callback function que retorna três objetos: request, response e ctx. E dentro dessa função de callback retorna uma função chamada response, que recebe dois parâmetros:

ctx.status(httpStatusCode) - aqui é onde passamos qual será o código de status que será simulado ou retornado da API fake, podendo ser qualquer um deles: 200, 201, 400, 401, 404, 500. O ctx é o context. Com essa função estamos determinando o cenário ou contexto que queremos apresentar ao teste.

ctx.json(mockResponse) - aqui é onde passamos quais serão os dados de retorno da API fake no formato JSON. Nesse caso utilizei apenas um objeto com apenas algumas propriedades que retorna da requisição real feita para o endereço https://api.github.com/users/deesouza.

Observações

Você pode usar a função rest do pacote msw para interceptar qualquer requisição de qualquer verbo do protocolo HTTP: [GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD]

Tendo esses pontos em mente, agora é testar a requisição e o retorno com o expect e teremos o resultado:

Espero que esse artigo o ajude de alguma maneira.

Referências

MSW JS

How to intercept a request with Axios

Diego Souza — Fri, 18 Sep 2020 12:53:06 +0000

Maybe, in your application you need to do a request with Axios using a token. But, you don't have a token yet. So, the application makes a request and then return an error with status code 401.

Fortunately, the Axios have a middleware that can help us to intercept the requests. For this, use the interceptors of instance of Axios thas was created.

import axios from 'axios';

const api = axios.create({
  baseURL: 'https://api.spotify.com/v1/',
});

api.interceptors.request.use(
  (request) => {
    if (api.defaults.headers.authorization) return request;

    throw new axios.Cancel('Token is not available. Do login, please.');
  },
  (error) => {
    return Promise.reject(error);
  },
);

export default api;

This code will avoid that the application from making the request and showing a error in the browser's console. The code check if exists a token in property Authorization, if a token is not found, the request won't be executed, returning an error from own Axios.

throw new axios.Cancel('Token is not available. Do login, please.');

This function Cancel from Axios is very important.

Do you know any other way to do this? Share with the community.