Forem: Junior

Como implementar internacionalização (i18n) em um projeto Next.js sem alterar a URL

Junior — Tue, 10 Jun 2025 10:26:32 +0000

Neste artigo, vou mostrar de forma objetiva e direta como implementar a internacionalização (i18n) em um projeto Next.js utilizando o next-intl, sem vincular os idiomas às rotas da URL — ou seja, nada de caminhos como example.com/en. Essa abordagem evita a necessidade de tratamentos extras caso o usuário altere a URL manualmente.

Utilizaremos um cookie para identificar e armazenar o idioma selecionado pelo usuário. Esse cookie será definido automaticamente no primeiro acesso ao site. Caso o usuário deseje alterar o idioma depois, será possível fazer essa mudança pela plataforma desenvolvida.

Configuração inicial

Caso ainda não tenha um projeto Next.js criado, você pode seguir este tutorial: Como configurar um novo projeto Next.js.

Agora, instale o pacote next-intl, que nos ajudará a configurar o i18n.

npm  install  next-intl

Vamos estruturar as pastas do projeto:

├── src
│   ├── app
│   │   ├── layout.tsx
│   │   └── page.tsx
│   ├── components
│   ├── hooks
│   └── i18n
│       ├── locales
│       │   ├── en-US.ts
│       │   └── pt-BR.ts
│       ├── config.ts
│       ├── locale.ts
│       └── request.ts
│   ├── services
│   └── styles

Hoje vamos focar apenas na pasta i18n. Em um próximo artigo, falarei mais sobre organização de pastas.

1 - Configurando o arquivo `layout.tsx` (ponto de entrada)

src/app/layout.tsx

import { Metadata } from 'next'
import { NextIntlClientProvider } from 'next-intl'
import { getLocale, getMessages } from 'next-intl/server'
import { ReactNode } from 'react'

export const metadata: Metadata = {
  title: 'NextJS',
  description: 'Site do NextJS'
}

async function RootLayout({ children }: { children: ReactNode }) {
  const locale = await getLocale()
  const messages = await getMessages()

  return (
    <html lang={locale}>
      <body>
        <NextIntlClientProvider messages={messages}>
          {children}
        </NextIntlClientProvider>
      </body>
    </html>
  )
}

Aqui, configuramos o NextIntlClientProvider, que recebe as mensagens do getMessages() e o idioma atual com getLocale() que ira para a tag html, ambos importados do next-intl/server.

2 - Configurando a pasta `i18n`

Essa estrutura serve para guardar todas as configurações relacionadas ao uso do i18n no projeto.

2.1 - Arquivo de `config.ts`

src/i18n/config.ts

export type LocaleProps = (typeof locales)[number]

export const locales = ['en-US', 'pt-BR'] as const
export const defaultLocale: LocaleProps = 'en-US'

Aqui exportamos as tipagens das idiomas que vamos usar no projeto.

2.2 - Arquivo de `locale.ts`

src/i18n/locale.ts

'use server'

import { cookies } from 'next/headers'

import { defaultLocale, LocaleProps } from './config'

const COOKIE_NAME = `${process.env.NEXT_PUBLIC_PROJECT_NAME}-i18n`

export async function getUserLocale() {
  return (await cookies()).get(COOKIE_NAME)?.value || defaultLocale
}

export async function setUserLocale(locale: LocaleProps) {
  ;(await cookies()).set(COOKIE_NAME, locale)
}

Esse arquivo é feito pra rodar no server, aqui gerenciamos todo buscar e alteração do cookie, ficar por sua escolha colocar o nome do projeto ou não para compor como vai ser chamado no cookie.

2.3 - Arquivo de `request.ts`

src/i18n/request.ts

import {
  useLocale as useNextIntlLocale,
  useTranslations as useNextIntlTranslations
} from 'next-intl'
import { getRequestConfig, setRequestLocale } from 'next-intl/server'

import { getUserLocale } from './locale'

export default getRequestConfig(async () => {
  const locale = await getUserLocale()
  return {
    locale,
    messages: (await import(`./locales/${locale}.ts`)).default
  }
})

export function setLocale(locale: 'pt-BR' | 'en-US') {
  setRequestLocale(locale)
}

export function useLocale() {
  const locale = useNextIntlLocale()
  return locale
}

export function useTranslations() {
  const t = useNextIntlTranslations()
  return t as (key: string) => string
}

O arquivo request deixou para buscar e montagem do json dos locales(Que vem da pasta locales que vou explicar logo abaixo) um wrapper de atualizar a linguagem, buscar a que está ativa no momento e também um para tradução. Esse formato ajuda caso um dia chegue a trocar a lib next-intl, só preciso trocar nessas funções e todo o projeto continuará funcionando.

2.4 - Pasta `locales`

Essa pasta contem os arquivos que guardam todos as traduções do nosso projeto.

Por exemplo:

export default {
  English: 'English',
  Portuguese: 'Portuguese',
 'Page not found': 'Page not found',
}

src/i18n/locales/en-US.ts

export default {
  English: 'Inglês',
  Portuguese: 'Português',
 'Page not found': 'Página não encontrada',
}

src/i18n/locales/pt-BR.ts

Um detalhe: utilizo as chaves das traduções como o próprio texto (no padrão inglês). Isso facilita o fallback quando há erro na biblioteca de tradução — ao menos o sistema exibe o texto em inglês. Além disso, evita duplicação e facilita a leitura e manutenção do JSON, especialmente em sistemas grandes.

Exemplo de uso normal.

export default {
  notFound: 'Página não encontrada',
  pageNotFound: 'Página não encontrada',
}

Isso é fácil de gerenciar em arquivos pequenos, mas vira um grande desafio em projetos grandes.

Exemplo de uso 1

import { useTranslations } from 'next-intl'

export default function HomePage() {
  const t = useTranslations()

  return (
    <div>
      <h1>{t('title')}</h1>
      <h1>{t('subtitle')}</h1>
    </div>
  )
}

Exemplo de uso 2

import { useTranslations } from 'next-intl'

export default function HomePage() {
  const t = useTranslations()

  return (
    <div>
      <h1>{t('Home page')}</h1>
      <h1>{t('Home page subtitle')}</h1>
    </div>
  )
}

Eu particularmente prefiro o Exemplo de uso 1.

Atenção: O next-intl pode gerar erro se a chave tiver um ponto no final, tipo 'Home page.'. Isso não acontece com a lib react-i18next (tema para um próximo artigo 😄).

Um outro ponto que gosto de fazer com essa arquitetura de organização é separar os json de tradução do projeto.

Por exemplo.

Nesse exemplo temos duas pasta de i18n uma em cada modulo(Padrão de modulo consistem em centralizar tudo em seus modulos como o de Auth, Home, User, Profile, Company para facilitar uma manutenção e merge posso trabalhar esse ponto em artigos futuro 😄).

Agora vamos ver como ficaria o nosso arquivo de locales.

import Auth from '@/app/(auth)/i18n/en-US'
import Dashboard from '@/app/(dashoard)/i18n/en-US'

export default {
  English: 'English',
  'Page not found': 'Page not found',
  ...Auth,
  ...Dashboard 
}

Com o uso do spread, mantemos os arquivos menores e organizados. E como usamos o próprio texto como chave, evitamos conflitos entre módulos.

Vamos usar o que construímos

Para usar em nosso projeto tem algumas abordagem a mais simples seria assim.

import { useTranslations } from 'next-intl'

export default function HomePage() {
  const t = useTranslations()

  return (
    <div>
      <h1>{t('Home page')}</h1>
      <h1>{t('Home page subtitle')}</h1>
    </div>
  )
}

Porém esse formato você já viu, vamos melhorar ele?

import { useTranslations } from 'next-intl'

interface TypographyProps {
  text: string
  className?: string
  length?: number
  variant?: 'h1' | 'h2' | 'h3' | 'h4' | 'h5' | 'h6' | 'p' | 'span' | 'strong'
}

function Typography({ variant, text, className, length }: TypographyProps) {
  const Component = variant || 'span'
  const t = useTranslations()
  const textTranslation = t(text)

  return (
    <Component className={className}>
      {length && textTranslation.length > length ? (
        <>{textTranslation.substring(0, length)}...</>
      ) : (
        textTranslation
      )}
    </Component>
  )
}

export { Typography }

Aqui criamos um componente Typography que ele pode ser qualquer uma das tags html que ele recebe como prop, e o mesmo também recebe uma prop text que já vai ser traduzida no próprio componente, além disso, pode passar uma lenght para um limite no texto a ser exibido. Assim não precisa em todo arquivo do seu projeto ficar importando o useTranslations() esse mesmo formato pode se estender para label de input e etc.

Conclusão

Existem várias formas de organizar e aplicar i18n no seu projeto. Neste artigo, compartilhei um modelo que gosto e acho bastante produtivo. Ele pode não ser o "melhor", mas é funcional, escalável e fácil de manter. Sinta-se à vontade para adaptá-lo e evoluí-lo conforme as necessidades dos seus projetos.

How to implement internationalization (i18n) in a Next.js project without changing the URL

Junior — Tue, 10 Jun 2025 10:26:28 +0000

In this article, I will objectively and directly show how to implement internationalization (i18n) in a Next.js project using next-intl, without tying languages to the URL paths — in other words, no paths like example.com/en. This approach avoids the need for extra handling in case the user manually changes the URL.

We'll use a cookie to identify and store the user's selected language. This cookie will be automatically set on the user's first visit to the site. If the user wishes to change the language later, they’ll be able to do so through the developed platform.

Initial setup

If you don’t have a Next.js project set up yet, you can follow this tutorial: How to set up a new Next.js project.

Now, install the next-intl package, which will help us configure i18n.

npm  install  next-intl

Let’s structure the project folders:

├── src
│   ├── app
│   │   ├── layout.tsx
│   │   └── page.tsx
│   ├── components
│   ├── hooks
│   └── i18n
│       ├── locales
│       │   ├── en-US.ts
│       │   └── pt-BR.ts
│       ├── config.ts
│       ├── locale.ts
│       └── request.ts
│   ├── services
│   └── styles

Today we’ll focus only on the i18n folder. In a future article, I’ll talk more about folder organization.

1 - Configuring the layout.tsx file (entry point)

src/app/layout.tsx

import { Metadata } from 'next'
import { NextIntlClientProvider } from 'next-intl'
import { getLocale, getMessages } from 'next-intl/server'
import { ReactNode } from 'react'

export const metadata: Metadata = {
  title: 'NextJS',
  description: 'Site do NextJS'
}

async function RootLayout({ children }: { children: ReactNode }) {
  const locale = await getLocale()
  const messages = await getMessages()

  return (
    <html lang={locale}>
      <body>
        <NextIntlClientProvider messages={messages}>
          {children}
        </NextIntlClientProvider>
      </body>
    </html>
  )
}

Here, we configure the NextIntlClientProvider, which receives messages from getMessages() and the current language from getLocale(), both imported from next-intl/server.

2 - Setting up the `i18n` folder

This structure stores all configurations related to i18n usage in the project.

2.1 - `config.ts` file

src/i18n/config.ts

export type LocaleProps = (typeof locales)[number]

export const locales = ['en-US', 'pt-BR'] as const
export const defaultLocale: LocaleProps = 'en-US'

Here we export the language typings that will be used in the project.

2.2 - `locale.ts` file

src/i18n/locale.ts

'use server'

import { cookies } from 'next/headers'

import { defaultLocale, LocaleProps } from './config'

const COOKIE_NAME = `${process.env.NEXT_PUBLIC_PROJECT_NAME}-i18n`

export async function getUserLocale() {
  return (await cookies()).get(COOKIE_NAME)?.value || defaultLocale
}

export async function setUserLocale(locale: LocaleProps) {
  ;(await cookies()).set(COOKIE_NAME, locale)
}

This file runs on the server. Here, we manage reading and updating the cookie. It’s up to you whether or not to include the project name as part of the cookie key.

2.3 - `request.ts` file

src/i18n/request.ts

import {
  useLocale as useNextIntlLocale,
  useTranslations as useNextIntlTranslations
} from 'next-intl'
import { getRequestConfig, setRequestLocale } from 'next-intl/server'

import { getUserLocale } from './locale'

export default getRequestConfig(async () => {
  const locale = await getUserLocale()
  return {
    locale,
    messages: (await import(`./locales/${locale}.ts`)).default
  }
})

export function setLocale(locale: 'pt-BR' | 'en-US') {
  setRequestLocale(locale)
}

export function useLocale() {
  const locale = useNextIntlLocale()
  return locale
}

export function useTranslations() {
  const t = useNextIntlTranslations()
  return t as (key: string) => string
}

The request file handles retrieving and assembling the locale JSONs (from the locales folder, which I’ll explain below), updating the language, retrieving the active one, and also a translation wrapper. This format helps in case we ever want to change the next-intl library — we’d only need to update these functions and the whole project would still work.

2.4 - `locales` folder

This folder contains the files that store all translations of our project.

Example:

export default {
  English: 'English',
  Portuguese: 'Portuguese',
 'Page not found': 'Page not found',
}

src/i18n/locales/en-US.ts

export default {
  English: 'Inglês',
  Portuguese: 'Português',
 'Page not found': 'Página não encontrada',
}

src/i18n/locales/pt-BR.ts

One detail: I use the actual text (in English) as the translation keys. This simplifies fallbacks when there’s an error in the translation library — at least the system shows the English text. Also, it avoids duplication and makes the JSON easier to read and maintain, especially in large systems.

Standard usage example:

import { useTranslations } from 'next-intl'

export default function HomePage() {
  const t = useTranslations()

  return (
    <div>
      <h1>{t('title')}</h1>
      <h1>{t('subtitle')}</h1>
    </div>
  )
}

Example usage 2:

import { useTranslations } from 'next-intl'

export default function HomePage() {
  const t = useTranslations()

  return (
    <div>
      <h1>{t('Home page')}</h1>
      <h1>{t('Home page subtitle')}</h1>
    </div>
  )
}

I personally prefer Example 1.

Attention: next-intl may throw an error if a key ends with a period, like 'Home page.'. This doesn’t happen with the react-i18next library (topic for a future article 😄).

Another thing I like about this folder organization is separating the project’s translation JSONs.

For example:

In this example, we have two i18n folders — one in each module (a module pattern centralizes everything within its module, such as Auth, Home, User, Profile, Company — making maintenance and merges easier. I’ll go into detail in a future article 😄).

Now let’s see how our locales file would look:

import Auth from '@/app/(auth)/i18n/en-US'
import Dashboard from '@/app/(dashoard)/i18n/en-US'

export default {
  English: 'English',
  'Page not found': 'Page not found',
  ...Auth,
  ...Dashboard 
}

By using spread syntax, we keep files small and organized. And by using the text itself as keys, we avoid conflicts between modules.

Let’s use what we’ve built

To use this in our project, the simplest approach would be:

import { useTranslations } from 'next-intl'

export default function HomePage() {
  const t = useTranslations()

  return (
    <div>
      <h1>{t('Home page')}</h1>
      <h1>{t('Home page subtitle')}</h1>
    </div>
  )
}

But since you've already seen this format, let’s improve it:

import { useTranslations } from 'next-intl'

interface TypographyProps {
  text: string
  className?: string
  length?: number
  variant?: 'h1' | 'h2' | 'h3' | 'h4' | 'h5' | 'h6' | 'p' | 'span' | 'strong'
}

function Typography({ variant, text, className, length }: TypographyProps) {
  const Component = variant || 'span'
  const t = useTranslations()
  const textTranslation = t(text)

  return (
    <Component className={className}>
      {length && textTranslation.length > length ? (
        <>{textTranslation.substring(0, length)}...</>
      ) : (
        textTranslation
      )}
    </Component>
  )
}

export { Typography }

Here we created a Typography component that can be any HTML tag, received via the variant prop. It also accepts a text prop that will be translated inside the component. You can also set a length limit on the displayed text. This way, you don’t need to import useTranslations() in every file — you can extend this same pattern for inputs, labels, etc.

Conclusion

There are many ways to organize and apply i18n in your project. In this article, I shared a model that I personally like and find very productive. It might not be the "best", but it’s functional, scalable, and easy to maintain. Feel free to adapt and evolve it based on your project's needs.

Implementando tema dark e light no Next.js com Tailwind

Junior — Mon, 28 Apr 2025 14:15:12 +0000

Primeiramente, por que precisamos implementar tema dark e light nos nossos projetos?

Ter esse recurso não é um requisito que fará seu projeto ter ou não mais acesso, porém ajuda muito na experiência de uso, pois existem pessoas com diferentes preferências. Entendido esse ponto, vamos ao que interessa! 😄

Entendendo o recurso no Tailwind

Para configurarmos esse recurso no Tailwind, precisamos apenas adicionar ou remover a classe dark no elemento <body> do HTML e usar o prefixo dark: nas classes dos elementos que desejamos ter estilos diferentes para cada tema.

Por exemplo:

<div class="bg-gray-800 dark:bg-gray-500"></div>

Nesse cenário, o fundo será bg-gray-800 como padrão (modo claro) e bg-gray-500 quando o tema escuro estiver ativo.

Como funciona no Next.js

No Next.js é um pouco diferente, pois é necessário o apoio de uma biblioteca chamada next-themes.
Importante: você não é obrigado a usá-la — é totalmente possível implementar o mesmo recurso manualmente — porém, ela facilita bastante o desenvolvimento.

Vamos ver exemplos usando e não usando a biblioteca.

Exemplo sem usar a biblioteca

Aqui, você será responsável por:

Gerenciar o valor do tema no localStorage;
Detectar qual tema o sistema do usuário está utilizando para proporcionar uma melhor experiência.

// hooks/useTheme.ts
import { useEffect, useState } from 'react';

type Theme = 'light' | 'dark';

export function useTheme() {
  const [theme, setTheme] = useState<Theme>('light');

  // Detecta preferências do sistema
  useEffect(() => {
    const savedTheme = localStorage.getItem('theme') as Theme | null;
    if (savedTheme) {
      setTheme(savedTheme);
    } else {
      const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
      setTheme(prefersDark ? 'dark' : 'light');
    }
  }, []);

  // Atualiza a classe no <html> e salva no localStorage
  useEffect(() => {
    const root = document.documentElement;
    if (theme === 'dark') {
      root.classList.add('dark');
      root.classList.remove('light');
    } else {
      root.classList.add('light');
      root.classList.remove('dark');
    }
    localStorage.setItem('theme', theme);
  }, [theme]);

  return { theme, setTheme };
}

Exemplo usando a biblioteca `next-themes`

// provider/theme-provider.ts
'use client'

import { ThemeProvider as NextThemesProvider } from 'next-themes'
import * as React from 'react'

function ThemeProvider({ children, ...props }: React.ComponentProps<typeof NextThemesProvider>) {
  const [mounted, setMounted] = React.useState(false)

  React.useEffect(() => {
    setMounted(true)
  }, [])

  if (!mounted) {
    return <>{children}</>
  }

  return <NextThemesProvider {...props}>{children}</NextThemesProvider>
}

export { ThemeProvider }

Usando no layout raiz da aplicação:

async function RootLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="pt-BR">
      <body>
        <ThemeProvider
          attribute="class"
          defaultTheme="system"
          enableSystem
          disableTransitionOnChange
        >
          {children}
        </ThemeProvider>
      </body>
    </html>
  )
}

Ao usar a lib next-themes, ela já traz muitos recursos prontos, como:

defaultTheme="system", que automaticamente respeita a preferência do sistema do usuário;
Controle do tema via classes (class) no HTML;
Entre outras configurações que você pode conferir na documentação oficial: 👉 next-themes no npm

Conclusão

Ter tema dark e light no seu sistema não é um ponto crucial, mas é muito importante para melhorar a usabilidade e a interação do usuário com o seu projeto.

Implementing dark and light themes in Next.js with Tailwind

Junior — Mon, 28 Apr 2025 14:14:59 +0000

First, why do we need to implement dark and light themes in our projects?

Having this feature is not a requirement that will necessarily bring more traffic to your project, but it greatly improves the user experience, as people have different preferences.
With that understood, let's dive into how to do it! 😄

Understanding the feature in Tailwind

To configure this feature with Tailwind, you just need to add or remove the dark class on the <body> element and use the dark: prefix in the elements’ classes that you want to style differently based on the theme.

Example:

<div class="bg-gray-800 dark:bg-gray-500"></div>

In this example, the default background color will be bg-gray-800 (light mode), and when the dark theme is active, it will switch to bg-gray-500.

How it works in Next.js

In Next.js, it’s a bit different, because you’ll likely need some help from a library called next-themes.
Important: it’s not mandatory — you can achieve the same functionality manually — but using the library makes the development process much easier.

Let’s see examples both without and with the library.

Example without using the library

In this case, you are responsible for:

Managing the theme value in localStorage;
Detecting the user’s system theme to provide a better experience.

// hooks/useTheme.ts
import { useEffect, useState } from 'react';

type Theme = 'light' | 'dark';

export function useTheme() {
  const [theme, setTheme] = useState<Theme>('light');

  // Detect system preferences
  useEffect(() => {
    const savedTheme = localStorage.getItem('theme') as Theme | null;
    if (savedTheme) {
      setTheme(savedTheme);
    } else {
      const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
      setTheme(prefersDark ? 'dark' : 'light');
    }
  }, []);

  // Update <html> class and save to localStorage
  useEffect(() => {
    const root = document.documentElement;
    if (theme === 'dark') {
      root.classList.add('dark');
      root.classList.remove('light');
    } else {
      root.classList.add('light');
      root.classList.remove('dark');
    }
    localStorage.setItem('theme', theme);
  }, [theme]);

  return { theme, setTheme };
}

Example using the `next-themes` library

// provider/theme-provider.ts
'use client'

import { ThemeProvider as NextThemesProvider } from 'next-themes'
import * as React from 'react'

function ThemeProvider({ children, ...props }: React.ComponentProps<typeof NextThemesProvider>) {
  const [mounted, setMounted] = React.useState(false)

  React.useEffect(() => {
    setMounted(true)
  }, [])

  if (!mounted) {
    return <>{children}</>
  }

  return <NextThemesProvider {...props}>{children}</NextThemesProvider>
}

export { ThemeProvider }

And using it in your root layout:

async function RootLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="en">
      <body>
        <ThemeProvider
          attribute="class"
          defaultTheme="system"
          enableSystem
          disableTransitionOnChange
        >
          {children}
        </ThemeProvider>
      </body>
    </html>
  )
}

When using the next-themes library, you get many built-in features like:

defaultTheme="system", which automatically picks up the user’s system preference;
Managing theme changes through the classattribute;
Other customizations available in the official documentation: 👉 next-themes on npm

Conclusion

Having dark and light themes in your system is not absolutely critical, but it is very important to improve usability and the overall user interaction with your project.

5 tips to improve backend integration, React with Axios

Junior — Sun, 29 Jan 2023 15:02:05 +0000

Introduction

In most frontend applications we have to integrate with the backend and with that comes several libraries that we can use such as fetch, ajax, axios among others and each one has its characteristics, advantages and disadvantages.

But regardless of which one we are going to use in our application, we have to think of points to help us with maintenance and better communication so as not to affect the usability of the user.

In this post I will use axios with react and applying concepts that I consider extremely important that we should address in our applications. I will take into account that you already have a react project with axios installed.

1 - Encapsulate service

We must create a generic service called with the library that we chose to use for the integration and simply just use it in the application, with the same idea of components like card, inputs, among others that we already do.

First we have to create a http.js or http.ts file (Remembering that you can put another name if you want) to export the axios with the base url of our backend already configured.

import Axios from 'axios';

const http = Axios.create({
  baseURL: process.env.REACT_APP_URL,
});

export default http;

Now we must create another index.js or index.ts file where we will export the most commonly used http methods already wrapped in a try catch blog to deal with the errors of the calls right here. Here we are already using the file we created above http.ts to trigger the axios with the parameters, in future posts we will evolve this file.

import http from './http';

export default {
  async get(url: string) {
    try {
      const response = await http.get(url);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async post(url: string, send: object) {
    try {
      const response = await http.post(url, send);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async put(url: string, send: object) {
    try {
      const response = await http.put(url, send);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async delete(url: string) {
    try {
      await http.delete(url);
      return true;
    } catch (err: any) {
      return false;
    }
  },
};

In the end we will have a folder structure like this.

We'll be able to invoke the method on our components this way.

await services.post( '/authenticate', { email, password } );

But why is it necessary to use this approach?

When we work with a generic service and only import it into our application, it becomes simpler to maintain and modify later. See how we can do it below.

2 - Add headers to all requests

Now let's configure headers for all our requests, we'll need this point to pass token among other information that your backend may need as a business rule.

Let's create an axios interceptors for this, as it's the best way to not just repeat code. See the example below.

import Axios, { AxiosRequestConfig } from 'axios';

const http = Axios.create({
  baseURL: process.env.REACT_APP_URL,
});

http.interceptors.request.use((config: AxiosRequestConfig) => {
  const token = window.localStorage.getItem('token');
  if (!token) return config;
  if (config?.headers) {
    config.headers = { Authorization: `Bearer ${token}` };
  }
  return config;
});

export default http;

Here we have already retrieved the localstorage token and added it to all calls to the backend.

3 - Redirect unauthorized or unauthenticated user

We must have user redirection strategies when the user does not have authorization or permission so that he does not have the need to do this in our components.

For that we must create another interceptors to deal with this process.

import Axios, { AxiosRequestConfig } from 'axios';

const http = Axios.create({
  baseURL: process.env.REACT_APP_URL,
});

http.interceptors.request.use((config: AxiosRequestConfig) => {
  const token = window.localStorage.getItem('token');
  if (!token) return config;
  if (config?.headers) {
    config.headers = { Authorization: `Bearer ${token}` };
  }
  return config;
});

http.interceptors.response.use(
  (value) => {
    return Promise.resolve(value);
  },
  (error) => {
    const { isAxiosError = false, response = null } = error;

    if (isAxiosError && response && response.status === 401) {
      // User redirection rule for login page
      return Promise.reject(error);
    }
    if (isAxiosError && response && response.status === 403) {
      // User redirection rule for disallowed page
      return Promise.reject(error);
    }
    return Promise.reject(error);
  }
);

export default http;

Leave open where you want to send the user for both 401(Unauthenticated) and 403(Unauthorized). That way, even if the user manages to access a page that he couldn't, when the backend request comes back with the status code, the system will already direct him, this approach also works for when the token expires, which we'll see how to deal with later.

4 - Request retry pattern

Now we will need to apply a pattern retry to our requests so that our end user does not suffer from instabilities in the application as it may be undergoing a deploy or auto scaling of the infrastructure at the time of the call. For this we define a number of attempts in case the system returns error 500 or higher. Example below.

import Axios, { AxiosRequestConfig } from 'axios';

const http = Axios.create({
  baseURL: process.env.REACT_APP_URL,
});

http.interceptors.request.use((config: AxiosRequestConfig) => {
  const token = window.localStorage.getItem('token');
  if (!token) return config;
  if (config?.headers) {
    config.headers = { Authorization: `Bearer ${token}` };
  }
  return config;
});

http.interceptors.response.use(
  (value) => {
    return Promise.resolve(value);
  },
  (error) => {
    const { isAxiosError = false, response = null } = error;

    if (isAxiosError && response && response.status === 401) {
      // Regra de redirecionamento de usuário para página de login
      return Promise.reject(error);
    }
    if (isAxiosError && response && response.status === 403) {
      // Regra de redirecionamento de usuário para página de não permitido
      return Promise.reject(error);
    }
    return Promise.reject(error);
  }
);

let counter = 1;

http.interceptors.response.use(
  (response) => {
    return response;
  },
  (error) => {
    if (
      error.response.status >= 500 &&
      counter < Number(process.env.REACT_APP_RETRY)
    ) {
      counter++;
      return http.request(error.config);
    }
    counter = 1;
    return Promise.reject(error);
  }
);

export default http;

An interceptor was created so that it has a retry according to the number defined in process.env.REACT_APP_RETRY times when the request has a status code greater than 500.

5 - Refresh token

When we work with authentication, it is a good practice and security rule to have tokens that expire so that the user does not stay logged in forever even without using the application.

However, we have to solve the problem that if the token expires when the user cannot simply ask him to log in again, for that we have routes to refresh token.

We can improve our index.ts file so that it does this automatically during your application's route calls.

import http from './http';

async function refreshToken() {
  const value = Number(localStorage.getItem('expired'));
  if (value && new Date(value) < new Date()) {
    const result = await http.get('/refresh');
    localStorage.setItem('token', result.data.token);
    localStorage.setItem(
      'expired',
      String(new Date().setSeconds(result.data.expired))
    );
  }
}

export default {
  async get(url: string) {
    try {
      await refreshToken();
      const response = await http.get(url);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async post(url: string, send: object) {
    try {
      await refreshToken();
      const response = await http.post(url, send);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async put(url: string, send: object) {
    try {
      await refreshToken();
      const response = await http.put(url, send);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async delete(url: string) {
    try {
      await refreshToken();
      await http.delete(url);
      return true;
    } catch (err: any) {
      return false;
    }
  },
};

We created a refreshToken() function that will always be called before all our application calls. It would check if the token's expired has already passed, and if so, make a new call to the backend, renewing the token and the expired. Remembering that this logic works according to the backend and the refresh route, for example, has a time limit after passing from expired to renewing the token, that would be more of a business rule.

Conclusion

In this post we saw five ways to improve our communication with the backend and taking into account the best experience for the end user, there are many other approaches that can improve our backend call service, but just by implementing these concepts we will have better maintenance and usability of our system. In future posts we will see how to further improve this service.

References

Axios - https://axios-http.com/docs/intro
React - https://reactjs.org/

5 tips to improve integration with the backend, Angular and Rxjs

Junior — Sun, 29 Jan 2023 14:53:13 +0000

Introduction

Unlike react, we have many libraries to communicate with the backend as mentioned in this post 5 tips to improve integration with the backend, React with Axios, in angular it is recommended to use the HttpClient and the rxjs that come with it, of course we can still install an axios or use a fetch without problems.

Even though angular has these points, it is important to think of points to help us with maintenance and better communication so as not to affect the usability of the user.

1 - Encapsulate service

First we have to create an angular service http-request.service.ts (Remembering you can put another name if you want) it will contain all the generic http methods.

import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Router } from '@angular/router';
import { Observable } from 'rxjs';
import { take } from 'rxjs/operators';
import { environment } from 'src/environments/environment';

@Injectable({
  providedIn: 'root'
})
export class HttpRequestService {
  private uri = `${environment.url}`;

  constructor(private http: HttpClient, private router: Router) {}

  private httpRequest<Data>(method: string, url: string, options: any): Observable<any> {
    return this.http.request(method, `${this.uri}${url}`, { ...options }).pipe(take(1));
  }

  post<Data>(url: string, body: any): Observable<any> {
    return this.httpRequest('post', url, { body: body });
  }

  get<Data>(url: string, params?: any): Observable<any> {
    return this.httpRequest('get', url, { params: params });
  }

  put<Data>(url: string, body: any): Observable<any> {
    return this.httpRequest('put', url, { body: body });
  }

  delete<Data>(url: string): Observable<any> {
    return this.httpRequest('delete', url, {});
  }
}

We created an httpRequest function (already thinking about reuse) that is being used by all generic methods, as we will evolve it in the next topics.

In the end we will have a folder structure like this.

We will be able to use the service in our components this way.

Following good practices, we created a service in our module where all calls to our components are located.

import { Injectable } from '@angular/core';
import { HttpRequestService } from 'src/app/shared/http/http-request.service';

import { Authenticate } from '../model/authenticate';

@Injectable({
  providedIn: 'root'
})
export class AuthService {
  constructor(private httpRequest: HttpRequestService) {}

  login(user: Authenticate) {
    return this.httpRequest.post(`/authenticate`, user);
  }
}

Now just importing this service into our component and passing the data to it.

import { Component, OnInit } from '@angular/core';
import { FormBuilder, FormGroup, Validators } from '@angular/forms';

import { AuthService } from '../service/auth.service';

@Component({
  selector: 'app-login',
  templateUrl: './login.component.html',
  styleUrls: ['./login.component.scss']
})
export class LoginComponent implements OnInit {
  public loginForm!: FormGroup;
  public loading = false;
  public error = '';

  constructor(
    private _formBuilder: FormBuilder,
    private _authService: AuthService,
  ) {}

  ngOnInit(): void {
    this.loginForm = this._formBuilder.group({
      email: ['', [Validators.required, Validators.email]],
      password: ['', [Validators.required]]
    });
  }

  handleLogin() {
    this.loading = true;
    this._authService.login(this.loginForm.value).subscribe({
    next: data => {
        this.loginForm.reset();
        this.loading = false;
    },
    error: ({ error }) => {
        this.loading = false;
    }
    });
  }
}

But why is it necessary to use this approach?

When we work with a generic service and only import it into our application, it becomes simpler to maintain and modify later. See how we can do it below.

2 - Add headers to all requests

Now let's configure headers for all our requests, we'll need this point to pass token among other information that your backend may need as a business rule.

Let's create an interceptor file (remembering that you can put another name if you want) for this, as it is the best way to not just repeat code. See the example below.

import { HttpEvent, HttpHandler, HttpInterceptor, HttpRequest } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Observable } from 'rxjs';

interface Header {[key: string]: string}

@Injectable()
export class Intercept implements HttpInterceptor {
  intercept(httpRequest: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    if (httpRequest.headers.get('noHeader')) {
      const cloneReq = httpRequest.clone({
        headers: httpRequest.headers.delete('noHeader')
      });
      return next.handle(cloneReq);
    }

    const headers: Header = {
      Authorization: `Bearer ${localStorage.getItem('token') || ''}`
    };

    return next.handle(httpRequest.clone({ setHeaders: { ...headers } }));
  }
}

And let's reference that interceptor in our appModule.

import { HTTP_INTERCEPTORS, HttpClientModule } from '@angular/common/http';
import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { BrowserAnimationsModule } from '@angular/platform-browser/animations';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './layouts/app/app.component';
import { Intercept } from './shared/http/intercept';

@NgModule({
  declarations: [AppComponent],
  imports: [
    BrowserModule,
    HttpClientModule,
    AppRoutingModule,
    BrowserAnimationsModule
  ],
  providers: [
    {
      provide: HTTP_INTERCEPTORS,
      useClass: Intercept,
      multi: true
    },
  ],
  bootstrap: [AppComponent]
})
export class AppModule {}

Here we have already retrieved the localstorage token and added it to all calls to the backend.

3 - Redirect unauthorized or unauthenticated user

We must have user redirection strategies when the user does not have authorization or permission so that he does not have the need to do this in our components.

At this point, I'm going to leave the code ready for the redirection and the fourth topic for better use.

import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Router } from '@angular/router';
import { Observable } from 'rxjs';
import { retryWhen, scan, take } from 'rxjs/operators';
import { environment } from 'src/environments/environment';

@Injectable({
  providedIn: 'root'
})
export class HttpRequestService {
  private uri = `${environment.url}`;

  constructor(private http: HttpClient, private router: Router) {}

  private redirectUser(status: number): void {
    if (status === 401) {
      localStorage.clear();
      // User redirection rule for login page
      this.router.navigateByUrl('/login');
    }
    if (status === 403) {
      // User redirect rule to not allowed page
      this.router.navigateByUrl('/');
    }
  }

  private httpRequest<Data>(method: string, url: string, options: any): Observable<any> {
    return this.http.request(method, `${this.uri}${url}`, { ...options }).pipe(
      retryWhen(e =>
        e.pipe(
          scan((errorCount, error) => {
            this.redirectUser(error.status);
            if (errorCount >= environment.retryAttempts || error.status < 500) throw error;
            return errorCount + 1;
          }, 0)
        )
      ),
      take(1)
    );
  }

  post<Data>(url: string, body: any): Observable<any> {
    return this.httpRequest('post', url, { body: body });
  }

  get<Data>(url: string, params?: any): Observable<any> {
    return this.httpRequest('get', url, { params: params });
  }

  put<Data>(url: string, body: any): Observable<any> {
    return this.httpRequest('put', url, { body: body });
  }

  delete<Data>(url: string): Observable<any> {
    return this.httpRequest('delete', url, {});
  }
}

4 - Request retry pattern

With the help of the rxjs operators we can do a retryWhen as many times as configured in the retryAttempts environment every time the request has a status code greater than 500.

5 - Refresh token

When we work with authentication, it is a good practice and security rule to have tokens that expire so that the user does not stay logged in forever even without using the application.

However, we have to solve the problem that if the token expires when the user cannot simply ask him to log in again, for that we have routes to refresh token.

We can improve our http-request.service.ts service so that it does this automatically when calling routes from your application.

import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Router } from '@angular/router';
import { Observable } from 'rxjs';
import { retryWhen, scan, take } from 'rxjs/operators';
import { environment } from 'src/environments/environment';

interface Refresh {
  token: string;
  expired: number;
}

@Injectable({
  providedIn: 'root'
})
export class HttpRequestService {
  private uri = `${environment.url}`;

  constructor(private http: HttpClient, private router: Router) {}

  private refreshToken(httpRequest: Observable<any>): Observable<any> {
    const value: number = Number(localStorage.getItem('expired'));
    if (value && new Date(value) < new Date()) {
      this.refresh().subscribe(data => {
        localStorage.setItem('token', data.token);
        localStorage.setItem('expired', String(new Date().setSeconds(data.expired)));
        return httpRequest;
      });
    }
    return httpRequest;
  }

  private refresh(): Observable<Refresh> {
    return this.http.get<Refresh>(`${environment.url}/refresh `).pipe(take(1));
  }

  private notAuthorization(status: number): void {
    if (status === 401) {
      localStorage.clear();
      this.router.navigateByUrl('/login');
    }
  }

  private httpRequest<Data>(method: string, url: string, options: any): Observable<any> {
    return this.http.request(method, `${this.uri}${url}`, { ...options }).pipe(
      retryWhen(e =>
        e.pipe(
          scan((errorCount, error) => {
            this.notAuthorization(error.status);
            if (errorCount >= environment.retryAttempts || error.status < 500) throw error;
            return errorCount + 1;
          }, 0)
        )
      ),
      take(1)
    );
  }

  post<Data>(url: string, body: any): Observable<any> {
    return this.refreshToken(this.httpRequest('post', url, { body: body }));
  }

  get<Data>(url: string, params?: any): Observable<any> {
    return this.refreshToken(this.httpRequest('get', url, { params: params }));
  }

  put<Data>(url: string, body: any): Observable<any> {
    return this.refreshToken(this.httpRequest('put', url, { body: body }));
  }

  delete<Data>(url: string): Observable<any> {
    return this.refreshToken(this.httpRequest('delete', url, {}));
  }
}

We created a refreshToken() function that receives an Observable and returns the same, but it would check if the token's expired has already passed, and if so, make a new call to the backend, renewing the token and the expired. Remembering that this logic works according to the backend and the refresh route, for example, has a time limit after passing from expired to renewing the token, that would be more of a business rule.

Conclusion

To the next

References

Angular - https://angular.io/
Rxjs - https://rxjs.dev

5 dicas para melhorar integração com o backend, Angular e Rxjs

Junior — Sun, 24 Apr 2022 23:52:11 +0000

Introdução

Diferente do react que temos muitas bibliotecas para realizar comunicação com o backend como foi mencionado nesse post 5 dicas para melhorar integração com o backend, React com Axios, no angular é recomendado utilizar o HttpClient e o rxjs que já vem com ele, isso é claro que ainda podemos instalar um axios ou usar um fetch sem problemas.

Mesmo que no angular tenha esses pontos é importante pensar em pontos para nos ajudar na manutenção e uma melhor comunicação para não afetar a usabilidade do usuário.

1 - Encapsular serviço

Devemos criar um serviço genérico de chamada com a biblioteca que escolhemos usar para fazer a integração e simplesmente só utilizar o mesmo na aplicação, com um tudo a mesma ideia de componentes como card, inputs, entre outros que já fazemos.

Primeiro temos que criar um serviço do angular http-request.service.ts (Lembrando você pode colocar outro nome caso queira) ele irá conter todos os métodos http genéricos.

import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Router } from '@angular/router';
import { Observable } from 'rxjs';
import { take } from 'rxjs/operators';
import { environment } from 'src/environments/environment';

@Injectable({
  providedIn: 'root'
})
export class HttpRequestService {
  private uri = `${environment.url}`;

  constructor(private http: HttpClient, private router: Router) {}

  private httpRequest<Data>(method: string, url: string, options: any): Observable<any> {
    return this.http.request(method, `${this.uri}${url}`, { ...options }).pipe(take(1));
  }

  post<Data>(url: string, body: any): Observable<any> {
    return this.httpRequest('post', url, { body: body });
  }

  get<Data>(url: string, params?: any): Observable<any> {
    return this.httpRequest('get', url, { params: params });
  }

  put<Data>(url: string, body: any): Observable<any> {
    return this.httpRequest('put', url, { body: body });
  }

  delete<Data>(url: string): Observable<any> {
    return this.httpRequest('delete', url, {});
  }
}

Criamos uma função httpRequest (já pensando em reuso) que está sendo usada por todos os métodos genéricos, pois vamos evoluir ela nos próximo tópicos.

No final teremos uma estrutura de pasta assim.

Vamos poder usar o serviço em nossos componentes dessa maneira.

Seguindo as boas práticas criamos um serviço em nosso em nosso módulo onde ficar todas as chamadas de nosso componentes.

import { Injectable } from '@angular/core';
import { HttpRequestService } from 'src/app/shared/http/http-request.service';

import { Authenticate } from '../model/authenticate';

@Injectable({
  providedIn: 'root'
})
export class AuthService {
  constructor(private httpRequest: HttpRequestService) {}

  login(user: Authenticate) {
    return this.httpRequest.post(`/authenticate`, user);
  }
}

Agora só importando esse serviço em nosso componente e passando os dados para o mesmo.

import { Component, OnInit } from '@angular/core';
import { FormBuilder, FormGroup, Validators } from '@angular/forms';

import { AuthService } from '../service/auth.service';

@Component({
  selector: 'app-login',
  templateUrl: './login.component.html',
  styleUrls: ['./login.component.scss']
})
export class LoginComponent implements OnInit {
  public loginForm!: FormGroup;
  public loading = false;
  public error = '';

  constructor(
    private _formBuilder: FormBuilder,
    private _authService: AuthService,
  ) {}

  ngOnInit(): void {
    this.loginForm = this._formBuilder.group({
      email: ['', [Validators.required, Validators.email]],
      password: ['', [Validators.required]]
    });
  }

  handleLogin() {
    this.loading = true;
    this._authService.login(this.loginForm.value).subscribe({
    next: data => {
        this.loginForm.reset();
        this.loading = false;
    },
    error: ({ error }) => {
        this.loading = false;
    }
    });
  }
}

Mas porque se faz necessário utilizar essa abordagem?

Quando trabalhamos com serviço genérico e só importamos ele em nossa aplicação fica mais simples de realizar manutenção e de modificar posteriormente. Veja como podemos fazer abaixo.

2 - Adicionar headers a todas request

Agora vamos configurar headers a todas nossas request, vamos necessitar desse ponto para passar token entre outras informações que seu backend pode precisar como regra de negócio.

Vamos criar um arquivo interceptor (Lembrando você pode colocar outro nome caso queira) para isso, pois é a melhor maneira para não ficarmos só repetindo código. Veja o exemplo abaixo.

import { HttpEvent, HttpHandler, HttpInterceptor, HttpRequest } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Observable } from 'rxjs';

interface Header {[key: string]: string}

@Injectable()
export class Intercept implements HttpInterceptor {
  intercept(httpRequest: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    if (httpRequest.headers.get('noHeader')) {
      const cloneReq = httpRequest.clone({
        headers: httpRequest.headers.delete('noHeader')
      });
      return next.handle(cloneReq);
    }

    const headers: Header = {
      Authorization: `Bearer ${localStorage.getItem('token') || ''}`
    };

    return next.handle(httpRequest.clone({ setHeaders: { ...headers } }));
  }
}

E vamos referência esse interceptor em nosso appModule.

import { HTTP_INTERCEPTORS, HttpClientModule } from '@angular/common/http';
import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { BrowserAnimationsModule } from '@angular/platform-browser/animations';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './layouts/app/app.component';
import { Intercept } from './shared/http/intercept';

@NgModule({
  declarations: [AppComponent],
  imports: [
    BrowserModule,
    HttpClientModule,
    AppRoutingModule,
    BrowserAnimationsModule
  ],
  providers: [
    {
      provide: HTTP_INTERCEPTORS,
      useClass: Intercept,
      multi: true
    },
  ],
  bootstrap: [AppComponent]
})
export class AppModule {}

Aqui já recuperamos o token do localstorage e adicionamos a todas as chamadas ao backend.

3 - Redirecionamento usuário não autorizado ou não autenticado

Devemos ter estratégias de redirecionamento de usuário quando o mesmo não tiver autorização ou permissão para que não tenha a necessidade de fazer isso em nossos componentes.

Nesse ponto já vou deixar o código pronto do redirecionamento e do quarto tópico para melhor aproveitamento.

import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Router } from '@angular/router';
import { Observable } from 'rxjs';
import { retryWhen, scan, take } from 'rxjs/operators';
import { environment } from 'src/environments/environment';

@Injectable({
  providedIn: 'root'
})
export class HttpRequestService {
  private uri = `${environment.url}`;

  constructor(private http: HttpClient, private router: Router) {}

  private redirectUser(status: number): void {
    if (status === 401) {
      localStorage.clear();
      // Regra de redirecionamento de usuário para página de login
      this.router.navigateByUrl('/login');
    }
    if (status === 403) {
      // Regra de redirecionamento de usuário para página de não permitido
      this.router.navigateByUrl('/');
    }
  }

  private httpRequest<Data>(method: string, url: string, options: any): Observable<any> {
    return this.http.request(method, `${this.uri}${url}`, { ...options }).pipe(
      retryWhen(e =>
        e.pipe(
          scan((errorCount, error) => {
            this.redirectUser(error.status);
            if (errorCount >= environment.retryAttempts || error.status < 500) throw error;
            return errorCount + 1;
          }, 0)
        )
      ),
      take(1)
    );
  }

  post<Data>(url: string, body: any): Observable<any> {
    return this.httpRequest('post', url, { body: body });
  }

  get<Data>(url: string, params?: any): Observable<any> {
    return this.httpRequest('get', url, { params: params });
  }

  put<Data>(url: string, body: any): Observable<any> {
    return this.httpRequest('put', url, { body: body });
  }

  delete<Data>(url: string): Observable<any> {
    return this.httpRequest('delete', url, {});
  }
}

Deixe aberto para onde você deseja mandar o usuário tanto para 401(Não autenticado) e 403 (Não autorizado). Dessa maneira mesmo que o usuário conseguir acessar uma página que não poderia quando a request do backend voltar com o status code o sistema já irá direcioná-lo, essa abordagem serve também para quando token expira, que vamos ver como lidar com isso mais adiante.

4 - Pattern retry de request

Agora vamos precisar aplicar pattern retry em nossas requests para que o nosso usuário final não sofra com instabilidades na aplicação pois a mesma pode está passando por um deploy ou auto scaling da infraestrutura no momento da chamada. Para isso nós definimos um número de tentativas caso o sistema retorne erro 500 ou superior. Exemplo mostrando no.

Com o auxílio do operators do rxjs podemos fazer um retryWhen quantas vezes for configurado na environment retryAttempts toda vez que a request tenha status code maior igual a 500.

5 - Refresh token

Quando trabalhamos com autenticação é uma boa prática e regra de segurança termos tokens que expiram para que o usuário não fique logado para sempre mesmo sem usar a aplicação.

Porém temos que resolver o problema que se o token expirado quando o usuário não podemos simplesmente pedir para que o mesmo realize login novamente, para isso temos rotas para refresh token.

Podemos melhorar nosso serviço http-request.service.ts para que ele faça isso automaticamente durante as chamadas das rotas da sua aplicação.

import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Router } from '@angular/router';
import { Observable } from 'rxjs';
import { retryWhen, scan, take } from 'rxjs/operators';
import { environment } from 'src/environments/environment';

interface Refresh {
  token: string;
  expired: number;
}

@Injectable({
  providedIn: 'root'
})
export class HttpRequestService {
  private uri = `${environment.url}`;

  constructor(private http: HttpClient, private router: Router) {}

  private refreshToken(httpRequest: Observable<any>): Observable<any> {
    const value: number = Number(localStorage.getItem('expired'));
    if (value && new Date(value) < new Date()) {
      this.refresh().subscribe(data => {
        localStorage.setItem('token', data.token);
        localStorage.setItem('expired', String(new Date().setSeconds(data.expired)));
        return httpRequest;
      });
    }
    return httpRequest;
  }

  private refresh(): Observable<Refresh> {
    return this.http.get<Refresh>(`${environment.url}/refresh `).pipe(take(1));
  }

  private notAuthorization(status: number): void {
    if (status === 401) {
      localStorage.clear();
      this.router.navigateByUrl('/login');
    }
  }

  private httpRequest<Data>(method: string, url: string, options: any): Observable<any> {
    return this.http.request(method, `${this.uri}${url}`, { ...options }).pipe(
      retryWhen(e =>
        e.pipe(
          scan((errorCount, error) => {
            this.notAuthorization(error.status);
            if (errorCount >= environment.retryAttempts || error.status < 500) throw error;
            return errorCount + 1;
          }, 0)
        )
      ),
      take(1)
    );
  }

  post<Data>(url: string, body: any): Observable<any> {
    return this.refreshToken(this.httpRequest('post', url, { body: body }));
  }

  get<Data>(url: string, params?: any): Observable<any> {
    return this.refreshToken(this.httpRequest('get', url, { params: params }));
  }

  put<Data>(url: string, body: any): Observable<any> {
    return this.refreshToken(this.httpRequest('put', url, { body: body }));
  }

  delete<Data>(url: string): Observable<any> {
    return this.refreshToken(this.httpRequest('delete', url, {}));
  }
}

Criamos uma função de refreshToken() que recebe um Observable e retorna o mesmo porém ela iria verificar se expired do token já passou, e se sim já realizar uma nova chamada ao backend renovando o token e o expired. Lembrando essa lógica funciona de acordo com o backend e a rota de refresh por exemplo tem um tempo limite depois que passar do expired para se renovar o token ai seria mais regra de negócio.

Conclusão

Nesse post vimos cinco maneiras de melhorar nossa comunicação com o backend e levando em conta a melhor experiência para o usuário final, existem muitas outras abordagens que podem melhorar o nosso serviço de chamada ao backend, porém só em implementar esses conceitos já teremos uma melhor manutenção e usabilidade do nosso sistema. Em posts futuros veremos como melhorar ainda mais esse serviço.

Até a próxima

Referências

Angular - https://angular.io/
Rxjs - https://rxjs.dev

5 dicas para melhorar integração com o backend, React com Axios

Junior — Sun, 24 Apr 2022 22:15:28 +0000

Introdução

Na maior parte das aplicações frontend temos que fazer integrações com o backend e com isso vem várias bibliotecas que podemos usar como por exemplo fetch, ajax, axios entre outras e cada uma tem suas características, vantagens e desvantagens.

Mas independente de qual vamos utilizar em nossa aplicação temos que pensar em pontos para nos ajudar na manutenção e uma melhor comunicação para não afetar a usabilidade do usuário.

Nesse post vou utilizar o axios com o react e aplicando conceitos que considero de extrema importância que devemos abordar em nossas aplicações. Vou levar em consideração que você já tem um projeto react com o axios instalado.

1 - Encapsular serviço

Primeiro temos que criar um arquivo http.js ou http.ts (Lembrando você pode colocar outro nome caso queira) para exportar o axios com a base url do nosso backend já configurada.

import Axios from 'axios';

const http = Axios.create({
  baseURL: process.env.REACT_APP_URL,
});

export default http;

Agora devemos criar um outro arquivo index.js ou index.ts aonde vamos exportar os métodos comumente mais usados do http já envolvendo em um blog try catch para lidarmos com os erros das chamadas aqui mesmo. Aqui já estamos utilizando o arquivo que criamos acima do http.ts para acionar o axios com os parâmetros, em posts futuros vamos evoluir esse arquivo.

import http from './http';

export default {
  async get(url: string) {
    try {
      const response = await http.get(url);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async post(url: string, send: object) {
    try {
      const response = await http.post(url, send);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async put(url: string, send: object) {
    try {
      const response = await http.put(url, send);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async delete(url: string) {
    try {
      await http.delete(url);
      return true;
    } catch (err: any) {
      return false;
    }
  },
};

No final teremos uma estrutura de pasta assim.

Vamos poder invocar o método em nossos componentes dessa maneira.

await services.post( '/authenticate', { email, password } );

Mas porque se faz necessário utilizar essa abordagem?

Quando trabalhamos com serviço genérico e só importamos ele em nossa aplicação fica mais simples de realizar manutenção e de modificar posteriormente. Veja como podemos fazer abaixo.

2 - Adicionar headers a todas request

Agora vamos configurar headers a todas nossas request, vamos necessitar desse ponto para passar token entre outras informações que seu backend pode precisar como regra de negócio.

Vamos criar um interceptors do axios para isso, pois é a melhor maneira para não ficarmos só repetindo código. Veja o exemplo abaixo.

import Axios, { AxiosRequestConfig } from 'axios';

const http = Axios.create({
  baseURL: process.env.REACT_APP_URL,
});

http.interceptors.request.use((config: AxiosRequestConfig) => {
  const token = window.localStorage.getItem('token');
  if (!token) return config;
  if (config?.headers) {
    config.headers = { Authorization: `Bearer ${token}` };
  }
  return config;
});

export default http;

Aqui já recuperamos o token do localstorage e adicionamos a todas as chamadas ao backend.

3 - Redirecionamento usuário não autorizado ou não autenticado

Devemos ter estratégias de redirecionamento de usuário quando o mesmo não tiver autorização ou permissão para que não tenha a necessidade de fazer isso em nossos componentes.

Para isso devemos criar outro interceptors para lidar com esse processo.

import Axios, { AxiosRequestConfig } from 'axios';

const http = Axios.create({
  baseURL: process.env.REACT_APP_URL,
});

http.interceptors.request.use((config: AxiosRequestConfig) => {
  const token = window.localStorage.getItem('token');
  if (!token) return config;
  if (config?.headers) {
    config.headers = { Authorization: `Bearer ${token}` };
  }
  return config;
});

http.interceptors.response.use(
  (value) => {
    return Promise.resolve(value);
  },
  (error) => {
    const { isAxiosError = false, response = null } = error;

    if (isAxiosError && response && response.status === 401) {
      // Regra de redirecionamento de usuário para página de login
      return Promise.reject(error);
    }
    if (isAxiosError && response && response.status === 403) {
      // Regra de redirecionamento de usuário para página de não permitido
      return Promise.reject(error);
    }
    return Promise.reject(error);
  }
);

export default http;

4 - Pattern retry de request

import Axios, { AxiosRequestConfig } from 'axios';

const http = Axios.create({
  baseURL: process.env.REACT_APP_URL,
});

http.interceptors.request.use((config: AxiosRequestConfig) => {
  const token = window.localStorage.getItem('token');
  if (!token) return config;
  if (config?.headers) {
    config.headers = { Authorization: `Bearer ${token}` };
  }
  return config;
});

http.interceptors.response.use(
  (value) => {
    return Promise.resolve(value);
  },
  (error) => {
    const { isAxiosError = false, response = null } = error;

    if (isAxiosError && response && response.status === 401) {
      // Regra de redirecionamento de usuário para página de login
      return Promise.reject(error);
    }
    if (isAxiosError && response && response.status === 403) {
      // Regra de redirecionamento de usuário para página de não permitido
      return Promise.reject(error);
    }
    return Promise.reject(error);
  }
);

let counter = 1;

http.interceptors.response.use(
  (response) => {
    return response;
  },
  (error) => {
    if (
      error.response.status >= 500 &&
      counter < Number(process.env.REACT_APP_RETRY)
    ) {
      counter++;
      return http.request(error.config);
    }
    counter = 1;
    return Promise.reject(error);
  }
);

export default http;

Foi criando um interceptors para que tenha retentativa de acordo com o número que for definido em process.env.REACT_APP_RETRY vezes quando a request tenha status code maior igual a 500.

5 - Refresh token

Quando trabalhamos com autenticação é uma boa prática e regra de segurança termos tokens que expiram para que o usuário não fique logado para sempre mesmo sem usar a aplicação.

Porém temos que resolver o problema que se o token expirado quando o usuário não podemos simplesmente pedir para que o mesmo realize login novamente, para isso temos rotas para refresh token.

Podemos melhorar nosso arquivo index.ts para que ele faça isso automaticamente durante as chamadas das rotas da sua aplicação.

import http from './http';

async function refreshToken() {
  const value = Number(localStorage.getItem('expired'));
  if (value && new Date(value) < new Date()) {
    const result = await http.get('/refresh');
    localStorage.setItem('token', result.data.token);
    localStorage.setItem(
      'expired',
      String(new Date().setSeconds(result.data.expired))
    );
  }
}

export default {
  async get(url: string) {
    try {
      await refreshToken();
      const response = await http.get(url);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async post(url: string, send: object) {
    try {
      await refreshToken();
      const response = await http.post(url, send);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async put(url: string, send: object) {
    try {
      await refreshToken();
      const response = await http.put(url, send);
      return response;
    } catch (err: any) {
      return false;
    }
  },
  async delete(url: string) {
    try {
      await refreshToken();
      await http.delete(url);
      return true;
    } catch (err: any) {
      return false;
    }
  },
};

Criamos uma função de refreshToken() que sempre será chamada antes de todas as chamadas da nossa aplicação ela iria verificar se expired do token já passou, e se sim já realizar uma nova chamada ao backend renovando o token e o expired. Lembrando essa lógica funciona de acordo com o backend e a rota de refresh por exemplo tem um tempo limite depois que passar do expired para se renovar o token ai seria mais regra de negócio.

Conclusão

Referências

Axios - https://axios-http.com/docs/intro
React - https://reactjs.org/

Forem: Junior

Como implementar internacionalização (i18n) em um projeto Next.js sem alterar a URL

Configuração inicial

1 - Configurando o arquivo layout.tsx (ponto de entrada)

2 - Configurando a pasta i18n

2.1 - Arquivo de config.ts

2.2 - Arquivo de locale.ts

2.3 - Arquivo de request.ts

2.4 - Pasta locales

Vamos usar o que construímos

Conclusão

How to implement internationalization (i18n) in a Next.js project without changing the URL

Initial setup

1 - Configuring the layout.tsx file (entry point)

2 - Setting up the i18n folder

2.1 - config.ts file

2.2 - locale.ts file

2.3 - request.ts file

2.4 - locales folder

Let’s use what we’ve built

Conclusion

Implementando tema dark e light no Next.js com Tailwind

Primeiramente, por que precisamos implementar tema dark e light nos nossos projetos?

Entendendo o recurso no Tailwind

Como funciona no Next.js

Exemplo sem usar a biblioteca

Exemplo usando a biblioteca next-themes

Conclusão

Implementing dark and light themes in Next.js with Tailwind

First, why do we need to implement dark and light themes in our projects?

Understanding the feature in Tailwind

How it works in Next.js

Example without using the library

Example using the next-themes library

Conclusion

5 tips to improve backend integration, React with Axios

Introduction

1 - Encapsulate service

2 - Add headers to all requests

3 - Redirect unauthorized or unauthenticated user

4 - Request retry pattern

5 - Refresh token

Conclusion

References

5 tips to improve integration with the backend, Angular and Rxjs

Introduction

1 - Encapsulate service

2 - Add headers to all requests

3 - Redirect unauthorized or unauthenticated user

4 - Request retry pattern

5 - Refresh token

Conclusion

References

5 dicas para melhorar integração com o backend, Angular e Rxjs

Introdução

1 - Encapsular serviço

2 - Adicionar headers a todas request

3 - Redirecionamento usuário não autorizado ou não autenticado

4 - Pattern retry de request

5 - Refresh token

Conclusão

Referências

5 dicas para melhorar integração com o backend, React com Axios

Introdução

1 - Encapsular serviço

2 - Adicionar headers a todas request

3 - Redirecionamento usuário não autorizado ou não autenticado

4 - Pattern retry de request

5 - Refresh token

Conclusão

Referências

1 - Configurando o arquivo `layout.tsx` (ponto de entrada)

2 - Configurando a pasta `i18n`

2.1 - Arquivo de `config.ts`

2.2 - Arquivo de `locale.ts`

2.3 - Arquivo de `request.ts`

2.4 - Pasta `locales`

2 - Setting up the `i18n` folder

2.1 - `config.ts` file

2.2 - `locale.ts` file

2.3 - `request.ts` file

2.4 - `locales` folder

Exemplo usando a biblioteca `next-themes`

Example using the `next-themes` library