DEV Community: Lucas Lomeu

Hexagonal Architecture

Lucas Lomeu — Tue, 21 Jul 2026 13:03:40 +0000

Hexagonal Architecture

The main idea is relatively simple: business rules should be at the center of the application and shouldn't depend on the technologies around them.

Databases, APIs, Kafka, Redis, web frameworks, and other technologies are important, of course, but from the application's point of view, they are external details.

What is Hexagonal Architecture?

Hexagonal Architecture was proposed by Alistair Cockburn with the idea that an application should be usable and testable independently of the technologies connected to it. In other words, our business rules shouldn't be directly coupled to external technologies.

Let's take a simple example: Imagine an application with a feature for creating users. Today, it receives requests through a REST API and stores users in PostgreSQL.

In the future, however, we might need to create users from Kafka messages, or maybe replace PostgreSQL with MongoDB.

Ideally, none of these changes should require major changes to our business rules. This is exactly the kind of problem Hexagonal Architecture tries to solve.

A simple way to visualize it is:

External technologies connect to our application through well-defined points called Ports, while the components responsible for making those connections are called Adapters.

The Application Core

One of the most important ideas behind Hexagonal Architecture is protecting the core of the application, because that's where the parts that represent the actual behavior of the system live.

We can think of the core as having two main parts: the Domain, which contains business concepts and rules, and the Application, which contains the use cases responsible for coordinating those rules.

Think about a banking system. The rule that an account cannot withdraw more money than its available balance belongs to the domain.

On the other hand, "transfer money from account A to account B" is an application operation that needs to coordinate several steps to make that transfer happen.

That use case might need to:

Find account A.
Find account B.
Perform the debit and credit operations.
Persist the changes.
Publish an event.

The Use Case is responsible for coordinating this flow, while the important business rules remain in the domain.

The Direction of Dependencies

Dependencies should point toward the core, and the core shouldn't know about external details.

For example, this would create unwanted coupling:

public class CreateUserService {
    private final JpaRepository<UserEntity, Long> repository;
}

Our application logic now knows directly about JPA, which means an infrastructure decision has leaked into the application core.

With Hexagonal Architecture, we want to invert that dependency.

Instead of having the core depend on JPA, the core defines what it needs:

public interface UserRepository {
    User save(User user);
}

This interface knows nothing about JPA, Hibernate, PostgreSQL, MongoDB, or Spring Data. It simply says:

"For my application to work, I need something capable of saving a user."

The infrastructure is responsible for deciding how that will actually happen.

This idea is closely related to the Dependency Inversion Principle, the "D" in SOLID.

Ports

Ports are the communication points between the application core and the outside world. They are commonly divided into Input Ports and Output Ports.

Input Ports

An Input Port represents an operation that the application exposes to the outside world. In Java, it can be represented by an interface that defines the contract of a use case.

For example:

public interface CreateUserUseCase {
    User execute(CreateUserCommand command);
}

This represents something our application knows how to do: create a user.

A REST Controller can call this port, but so can a CLI or a Kafka Consumer. None of them need to know the internal details of how the use case is implemented.

For example:

@RestController
@RequestMapping("/users")
public class UserController {

    private final CreateUserUseCase createUserUseCase;

    public UserController(CreateUserUseCase createUserUseCase) {
        this.createUserUseCase = createUserUseCase;
    }

    @PostMapping
    public ResponseEntity<UserResponse> create(
        @RequestBody CreateUserRequest request
    ) {
        var command = new CreateUserCommand(
            request.name(),
            request.email()
        );

        var user = createUserUseCase.execute(command);

        return ResponseEntity.ok(
            new UserResponse(
                user.getId(),
                user.getName(),
                user.getEmail()
            )
        );
    }
}

Output Ports

Now imagine that our CreateUserUseCase needs to save a user.

To do that, the core needs to communicate with something external — in this case, a database.

But there's an important detail here: the Use Case doesn't need to know which database is being used.

It only needs to express a requirement:

"I need to save a user."

We can represent that requirement with an Output Port:

public interface UserRepository {
    User save(User user);
    boolean existsByEmail(String email);
}

Now we can implement our use case:

public class CreateUserService implements CreateUserUseCase {

    private final UserRepository userRepository;

    public CreateUserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public User execute(CreateUserCommand command) {
        if (userRepository.existsByEmail(command.email())) {
            throw new EmailAlreadyExistsException();
        }

        var user = User.create(
            command.name(),
            command.email()
        );

        return userRepository.save(user);
    }
}

Notice that CreateUserService knows about UserRepository, but it knows nothing about JpaRepository, Hibernate, PostgreSQL, or MongoDB.

From the use case's point of view, those details don't matter.

That decision belongs to the infrastructure.

Adapters

If Ports define the communication points between the core and the outside world, Adapters are responsible for connecting those points to specific technologies.

They can be divided into two groups: Input Adapters and Output Adapters. An Input Adapter starts an interaction with our application. A REST Controller, Kafka Consumer, or CLI are good examples. An Output Adapter connects our application to something external, such as PostgreSQL, MongoDB, Redis, or a Kafka Producer.

There's an important distinction here:

PostgreSQL itself is not an Adapter. The Adapter is the code responsible for connecting our application to PostgreSQL.

For example:

@Component
public class UserRepositoryAdapter implements UserRepository {

    private final SpringDataUserRepository repository;

    public UserRepositoryAdapter(
        SpringDataUserRepository repository
    ) {
        this.repository = repository;
    }

    @Override
    public User save(User user) {
        var entity = UserEntity.fromDomain(user);
        var saved = repository.save(entity);
        return saved.toDomain();
    }

    @Override
    public boolean existsByEmail(String email) {
        return repository.existsByEmail(email);
    }
}

If we decide to use MongoDB tomorrow, we could create a MongoUserRepositoryAdapter implementing the same UserRepository interface.

The CreateUserService wouldn't need to change.

Where Does the Domain Fit In?

So far, we've talked a lot about the "core", but the domain and the application aren't exactly the same thing.

Understanding this difference helps avoid a common mistake: putting every business rule inside Use Cases.

Imagine we have an Account entity:

public class Account {
    private AccountId id;
    private Money balance;

    public void withdraw(Money amount) {
        if (amount.isGreaterThan(balance)) {
            throw new InsufficientBalanceException();
        }

        balance = balance.subtract(amount);
    }
}

This validation shouldn't live in a Controller, a database, or a Use Case.

It belongs to the rules of an account itself.

The domain shouldn't need to depend on @RestController, @Entity, @Repository, KafkaTemplate, or RedisTemplate.

Ideally, the domain should be able to exist without even knowing that these technologies exist.

One Core, Different Technologies

One interesting consequence of this decoupling is that we can connect different adapters to the same application core.

Imagine we have a CreateUserUseCase.

Today, it's called by a REST API, but tomorrow we might add a Kafka Consumer.

Both can use exactly the same Use Case.

The same idea applies to the output side:

An in-memory adapter can also be useful for certain types of tests.

This shows one of the original ideas behind the architecture quite well:

"The application should be able to work regardless of how it is triggered or which technologies are connected to it."

When Does It Make Sense?

Hexagonal Architecture tends to make more sense for applications with:

Relevant business rules.
Multiple integrations.
Technologies that may need to be replaced or added over time.
Different ways of interacting with the application.
A strong need for isolated tests.
Systems expected to live and evolve for a long time.
A domain that needs to evolve independently from infrastructure.

Imagine, for example, a financial application that receives operations through REST, Kafka, or even Batch jobs, while also communicating with PostgreSQL, Redis, Kafka, and external banking APIs.

In this kind of system, controlling dependencies becomes increasingly important.

On the other hand, for a small and simple CRUD application, a more traditional architecture might be more than enough.

There's no reason to add architectural complexity just because a particular architecture is popular.

The cost of the architecture also needs to be considered. Creating ports, adapters, and abstractions for every operation adds indirection to the code.

That complexity should solve a real problem in the project.

Conclusion

Hexagonal Architecture isn't about creating more interfaces or following a specific folder structure.

It's about controlling the direction of dependencies.

For me, a simple way to summarize the idea is:

Your business rules should control the abstractions they need, instead of being controlled by the technologies they use.

In the end, Ports, Adapters, Input, and Output are ways of putting this idea into practice.

The exact structure can vary from project to project. What really matters is keeping clear boundaries between business logic and infrastructure.

A few months ago, I implemented some of these concepts in a URL shortener as a study project. If you're curious, the code is available on GitHub.

Building a Scalable URL Shortener

Lucas Lomeu — Tue, 10 Feb 2026 11:08:45 +0000

I thought a URL shortener was literally a simple CRUD. It turned out to be the exact opposite, so here’s how I designed and built mine.

The Problem

Let's understand what we're building:

What it does:

Convert https://website.com/very/long/url into short.com/aB3x
Redirect users from short URL back to the original
Handle 1,000+ writes/sec and 10,000+ reads/sec
Never generate duplicate short codes

What makes it hard:

IDs must be globally unique - no collisions
Read-heavy workload - 10:1 read/write ratio
Must scale horizontally

The Math Behind It

Let's do some napkin math to understand scale:

100 million URLs/day x (24 hours / 3600 ms) = ~1,160 writes/sec
10:1 read ratio - 1,160 writes/sec x 10 = ~11,600 reads/sec
Over 10 years - 100M x 365 days * 10 years = ~365 billion URLs

Architecture: Hexagonal Pattern

I chose Hexagonal Architecture because it keeps the business logic independent from infrastructure. This makes it easier to swap databases, frameworks, or transport layers without touching the core of the application. It also aligns with what I’ve been studying lately, since I plan to dive deeper into this architecture and eventually write an article about it.

Database Choice: PostgreSQL

Strong consistency – Ensures there are no duplicate short codes, even during network partitions
ACID transactions – ID generation and insertion happen atomically
Simple operations – Around 99% of the queries are direct key lookups

Schema Design

CREATE SEQUENCE urls_id_seq;

CREATE TABLE urls (
  id BIGINT PRIMARY KEY DEFAULT nextval('urls_id_seq'),
  short_code VARCHAR(10) NOT NULL UNIQUE,
  long_url TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE UNIQUE INDEX idx_urls_short_code ON urls (short_code);

Why this works:

id is the source of truth (sequence-generated)
short_code has unique index for fast O(log n) lookups
No index on long_url (expensive, rarely queried)

The Core Problem: ID Generation

Generating short codes sounds simple, but in practice you need IDs that:
1. Are globally unique (no collisions)
2. Stay short (7 characters or less)
3. Don't require coordination between servers

Strategy: Sequence + Base62 Encoding

Here's the actual implementation:

public class ShortCodeGenerator implements ShortCodeGeneratorPort {
    private static final String BASE62 =
        "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";

    @Override
    public String generate(long id) {
        if (id <= 0) {
            throw new IllegalArgumentException("ID must be positive");
        }

        StringBuilder sb = new StringBuilder();
        long n = id;

        while (n > 0) {
            int remainder = (int) (n % 62);
            sb.append(BASE62.charAt(remainder));
            n /= 62;
        }

        return sb.reverse().toString();
    }
}

Why this is collision-free:

PostgreSQL sequence guarantees unique IDs (1, 2, 3, ...)
Base62 is a bijective function: unique ID -> unique code
If ID1 != ID2, then Base62(ID1) != Base62(ID2)
No retry logic needed

Capacity Analysis

Length	Possible URLs	Years at 1k/sec
5 chars	916 million	29 years
6 chars	56.8 billion	1,800 years
7 chars	3.52 trillion	111,000 years

With 7 characters, we’re set for a while. We only need about 365 billion.

Caching

At ~10k reads/sec, PostgreSQL was fine. But I knew the moment traffic spiked, the DB would start being the bottleneck.

What surprised me the most was how visible the change became after adding cache.

The Problem

Every request:
1. App -> PostgreSQL: "SELECT * FROM urls WHERE short_code = 'aB3x'"
2. PostgreSQL -> Disk: Read from index + table
3. PostgreSQL -> App: Return result
4. App -> Client: 302 redirect

Latency: 5-10ms per request

Even with indexes, disk I/O is expensive and most users keep hitting the same short URLs.

Solution: Cache‑Aside with Redis

The pattern is simple:

1. Try Redis first
2. If miss -> query in Database
3. Store in Redis for next time

This gave me the best of both worlds: resilience (if Redis dies, the system still works) and speed (most reads never touch the DB).

API Design

Keep it simple:

Create Short URL

POST /api/v1/shorten
Content-Type: application/json

{
  "url": "https://website.com/very/long/url"
}

Response:

{
  "shortCode": "aB3x"
}

Redirect

GET /aB3x
GET /api/v1/aB3x

Returns 302 Found with Location: https://website.com/very/long/url

Why 302 instead of 301?

301 (permanent) gets cached by browsers -> no click tracking
302 (temporary) hits your server every time -> you can measure clicks or any metrics

For a URL shortener with analytics, 302 is the right choice.

Code Structure

Here's the actual file structure:

src/main/java/org/lomeu/
├── application/
│   ├── service/
│   │   └── UrlService.java         (use case orchestration)
│   └── port/
│       ├── in/
│       │   └── UrlUseCase.java     (inbound port)
│       └── out/
│           ├── UrlRepository.java  (outbound port)
│           └── ShortCodeGeneratorPort.java
│
├── domain/
│   └── Url.java                    (pure domain model)
│
├── infrastructure/
│   ├── http/
│   │   └── UrlController.java      (HTTP adapter)
│   ├── database/
│   │   ├── Database.java           (connection pool)
│   │   └── JdbcUrlRepository.java  (persistence adapter)
│   └── generator/
│       └── ShortCodeGenerator.java (Base62 implementation)
│
├── config/
│   └── AppConfig.java
│
└── Main.java                        (entry point + shutdown hook)

The complete implementation at github.com/lucaslomeu/url-shortener.

Arquitetura Fullstack com Angular 19 + Spring Boot

Lucas Lomeu — Mon, 05 May 2025 11:11:21 +0000

Neste post, compartilho um pouco da experiência de desenvolver uma aplicação fullstack real com Angular 19, Spring Boot e Docker.

O objetivo não é ensinar passo a passo, mas sim apresentar as decisões técnicas, aprendizados e desafios enfrentados ao longo do projeto.

Ao abordar tópicos como autenticação JWT, arquitetura, integração entre frontend e backend e containerização.

📌 Sobre o projeto

O Mony é uma aplicação web para controle de assinaturas e finanças pessoais. A ideia é oferecer uma forma simples de:

Cadastrar serviços recorrentes (como Netflix, Spotify, etc.)
Visualizar todos os gastos mensais
Ter uma visão clara sobre o orçamento

O foco desse projeto foi estruturar um app fullstack moderno (por isso a escolha do Angular 19) com boas práticas de frontend, backend e containerização com Docker

🔧 Tecnologias utilizadas

Frontend: Angular 19 + Tailwind CSS v4
Backend: Java 11 - Spring Boot + Spring Security + JWT + Spring Data JPA
Banco de dados: PostgreSQL 15
Containerização: Docker + Docker Compose

🧱 Arquitetura da aplicação

Visão geral da arquitetura lógica da aplicação:

🧬 Modelo de dados

As entidades principais do sistema são MonyUser, Subscription, Category e Address. Veja como elas se relacionam:

🗂️ Estrutura do Projeto

mony/
├── server/        # Backend Spring Boot
│   └── ...        # Controllers, DTOs, Repositories, etc.
├── client/        # Frontend Angular 19
│   └── ...        # Features, Shared Modules, Layout

A descrição completa das pastas e suas responsabilidades está disponível no README do repositório.

🧰 Uso do Lombok no backend

Durante o desenvolvimento do backend, utilizei o Project Lombok para reduzir o boilerplate nas classes Java, especialmente nas entidades, DTOs e serviços.

Com anotações como @Getter, @Setter, @NoArgsConstructor, @AllArgsConstructor e @Builder, consegui manter o código mais limpo, legível e focado na lógica de negócio, evitando repetições desnecessárias de métodos.

Além de deixar as classes mais enxutas, o uso do Lombok contribuiu para a produtividade e organização geral do projeto.

🔐 Autenticação JWT com Spring Security

Implementei autenticação e autorização com JWT no backend, protegendo todos os endpoints sensíveis. A geração e validação dos tokens são feitas com filtro personalizado no Spring Security.

No frontend, o Angular armazena o token localmente com LocalStorage e utiliza um HTTPInterceptor para enviá-lo automaticamente em cada requisição autenticada.

💡 Principal no backend

Durante a implementação, tive que decidir como lidar com os dados do usuário autenticado no backend.

Inicialmente, pensei em enviar o ID do usuário em cada requisição ou armazenar algo no LocalStorage, mas isso abriria espaço para falhas de segurança.

Foi nesse momento que conheci a interface Principal do Spring — algo novo pra mim até então. Ela resolvia exatamente o que eu buscava: deixava o backend 100% responsável por identificar o usuário autenticado, com base no JWT.

Isso permitiu que cada controller acessasse diretamente o contexto do usuário logado sem depender de nenhuma informação adicional do frontend.

Resultado: código mais limpo, seguro e desacoplado.

A partir disso, todos os controllers que precisam de contexto do usuário simplesmente recebem o Principal como parâmetro. Com isso, o backend consegue filtrar ou associar dados automaticamente ao usuário autenticado, mantendo a integridade dos dados e a segurança da aplicação.

📦 Docker Compose: backend + frontend + PostgreSQL

Para facilitar o desenvolvimento e isolar os serviços, configurei um ambiente completo com Docker Compose.

services:
  - PostgreSQL 15 (banco de dados)
  - Spring Boot (backend)
  - Angular 19 (frontend)

E com o comando abaixo, toda a aplicação sobe em containers:

docker-compose up --build

🧠 Aprendizados e desafios técnicos

Enquanto desenvolvia o Mony, tive a oportunidade de aprofundar e aplicar conceitos importantes em várias áreas do stack fullstack moderno:

🔷 Frontend (Angular 19)

Estruturei a aplicação com lazy loading e arquitetura modular por feature, seguindo boas práticas para escalabilidade.
Usei o Tailwind CSS v4 para estilização rápida, com foco em produtividade e responsividade.
Como venho de projetos com versões mais antigas do Angular (8, 11, 14), esse projeto foi também uma oportunidade para aplicar as novidades das versões mais recentes. Entre os destaques:
- inject(): substitui a injeção de dependência tradicional via construtor. O código ficou mais limpo e menos verboso, especialmente em componentes simples ou standalone.
- @computed(): facilita a criação de propriedades derivadas e reativas sem depender de rxjs, tornando o código mais declarativo, previsível e legível.
- @for e @if: evoluções das diretivas estruturais (*ngFor, *ngIf) que tornam o HTML mais moderno e direto, eliminando a necessidade de blocos ng-template e melhorando a performance.
- resource(): uma das features que mais gostei (mesmo ainda sendo experimental). Permite declarar loader e request de forma reativa e integrada ao ciclo de vida, gerenciando chamadas assíncronas com muito menos código, utilizando signals.
- effect(): executa funções automaticamente sempre que um signal dependente muda de valor. Usei no serviço de CEP, por exemplo, para atualizar campos dinamicamente conforme o usuário escolhia um estado, assim o DOM respondia instantaneamente.

🔶 Backend (Spring Boot)

Configuração completa do Spring Security com autenticação via JWT
Implementação de filtros personalizados para validar tokens
Uso da interface Principal para identificar automaticamente o usuário logado sem expor dados no frontend
Mapeamento e relacionamento de entidades com JPA, incluindo um cenário N:N usando @ManyToMany com @JoinTable
Separação clara entre DTOs, entidades, serviços e repositórios

🤝 Conclusão

Você pode conferir o código completo aqui:

🔗 Repositório no GitHub - Mony

📋 Resumo técnico

✅ Stack: Angular 19, Spring Boot, PostgreSQL
🧠 Auth: JWT + Spring Security + Principal
🐳 Dev: Docker Compose com 3 containers
🧰 Extras: Lombok, Tailwind, ng2-charts

Linux Basics: Essential Terminal Commands

Lucas Lomeu — Mon, 13 Nov 2023 11:44:37 +0000

Linux Terminal Commands

Listing

The ls command is used to list files and directories. Here are some common options:

-a or --all: Lists all files, including hidden files.
-l: Displays additional information about files and directories.
-h: Formats file sizes in a human-readable format.
-R: Lists directories and their contents recursively.

ls [path] -a -l -h -R

Example:

ls -a -l -h -R

Change Directory

The cd command is used to navigate between directories.

To go back to the parent directory, use ...

Example:

cd [path]

To go back one directory:

cd ..

Copy

The cp command is used to copy files or directories to another location. The -r option is used to copy directories and their contents recursively.

Example:

cp -r [source] [destination]

Move

The mv command is used to move files or directories to another location. It can also be used to rename files and directories.

Example:

mv [source] [destination]

Remove

The rm command is used to remove files or directories. The -r option removes directories and their contents recursively, while -f forces the operation without prompting for confirmation.

Use this command carefully, especially when using -r and -f.

Example:

rm -rf [path or file]

Make Directory

The mkdir command creates a new directory. You can provide either the full path or just the directory name.

Example:

mkdir [path]

Remove Directory

The rmdir command removes an empty directory. You can provide either the full path or just the directory name.

Example:

rmdir [path]

Empty File

The touch command can be used to create an empty file with the specified name.

Example:

touch [file]

Text Editor

You can open and edit text files directly from the terminal using a text editor such as nano or vi.

Example:

nano [file]

or:

vi [file]

Superuser

The sudo command is used to execute commands with elevated privileges.

Example:

sudo [command]

Clear

The clear command clears the terminal screen.

Example:

clear

Promises em JavaScript: entendendo o básico

Lucas Lomeu — Sun, 13 Mar 2022 17:03:30 +0000

PROMISES

Antes de entendermos as Promises, temos de conhecer as diferenças entre comportamentos síncronos e assíncronos.

Síncrono e Assíncrono

Como o próprio nome pode nos ajudar a deduzir, síncrono acontece em sincronia, ou seja, que ocorre em mesmo tempo que outra coisa. Já assíncrono é o oposto, é algo que não acontece junto com outra coisa. Podemos exemplificar esses comportamentos síncronos e assíncronos, como uma chamada de telefone e envio de e-mail, respectivamente.

Sabendo o básico, podemos afirmar que o Javascript é síncrono, sendo executado linearmente de cima para baixo. Isso se deve ao fato que ela é uma linguagem Single Thread, então cada linha de comando só será executada quando a anterior é finalizada.

console.log('Primeira linha');
console.log('Segunda linha');
console.log('Terceira linha');
console.log('Quarta linha');
console.log('Quinta linha');

Sendo assim, o código acima quando executado, nos retorna:

Primeira linha
Segunda linha
Terceira linha
Quarta linha
Quinta linha

No Javascript temos a função assíncrona setTimeout(), onde no primeiro parâmetro ela espera uma função e no segundo o tempo que após ser feita a chamada da função, ela será executada, isso em milissegundos.

Sendo assim, vamos analisar o código abaixo:

console.log('Primeira linha');
console.log('Segunda linha');

setTimeout(() => {
  console.log('setTimeout');
}, 2000);

console.log('Terceira linha');
console.log('Quarta linha');
console.log('Quinta linha');

Caso a função setTimeout() fosse síncrona, deveriamos ter o retorno abaixo, já que está sendo chamado na terceira linha:

Primeira linha
Segunda linha
setTimeout
Terceira linha
Quarta linha
Quinta linha

Porém, ela é uma função que não acontece junto com outra coisa -assíncrona - ela só sera retornada com uma condição ou parâmetro, que no caso, é ser executada após 2 segundos, nos retornando:

Primeira linha
Segunda linha
Terceira linha
Quarta linha
Quinta linha
setTimeout

Ou seja, ela executa todas as outras linhas de maneira síncrona, quando chega no setTimeout(), ela é entregue para uma request separada que é executada fora da thread do Javascript - lembrando que o código que escrevemos é executado em uma única thread - fazendo com que o restante continue a ser executado.

Agora já com o conhecimento de síncrono/assíncrono, podemos tratar das Promises. Como o próprio nome diz, é uma promessa que pode ou não estar disponível em algum momento, sendo assim, ela possui um comportamento assíncrono.

Promise é um objeto que possui três possíveis estados, sendo eles:

Pending – Estado inicial, pendente de execução
Fulfilled – Concluido com sucesso
Rejected – Ocorreu algum erro

A mesma recebe dois parâmetros, sendo eles comumente chamados de resolve e reject, sendo assim, apenas um dos métodos de tratamento será chamado. Para acessar a resposta dessa promisse, temos o .then e o .catch, sendo responsáveis por tratar a resposta e o erro respectivamente.

O método .then irá registrar um _callback _de sucesso e é comum executar duas ou mais operações assíncronas consecutivas, executando a ação posterior apenas quando a anterior for bem sucedida, isso é possível realizando o encadeamento do método .then, onde o mesmo retorna uma nova promise diferente da original.

 new Promise((resolve, reject) => {
  console.log('Inicio da Promise');
  const numero = 10;

  resolve(numero);
})
  .then((value) => {
    console.log(`Primeiro valor: ${value}`);
    return value;
  })
  .then((newValue) => {
    console.log(`Valor somado de 5: ${newValue + 5}`);
  });

No código foi chamado a função construtora passando os dois parâmetros como argumento e a chamada de uma função callback.
Logo de início já é executado nosso primeiro console.log e o armazenamento de numero em uma constante, recebendo o valor 10, logo após chamamos nosso resolve(numero), passando como resolvida nossa promise e ela recebe esse número.

Agora devemos tratar esse resultado fazendo a chamada do nosso primeiro .then onde o mesmo recebe um parâmetro value, esse valor recebe o que foi passado em resolve, logo value equivale a numero, sendo assim, chamamos o console.log desse value e retornamos ele para que possamos utilizar no próximo encadeamento de .then, onde iremos tratar o retorno anterior.
Para diferenciarmos, foi passado como parâmetro agora newValue onde o mesmo recebeu o valor anterior e será tratado no console, sendo acrescido de 5.

O resultado final desse código:

new Promise((resolve, reject) => {
  console.log('Inicio da Promise');
  const numero = 10;

  resolve(numero);
})
  .then((value) => {
    console.log(`Primeiro valor: ${value}`);
    return value;
  })
  .then((newValue) => {
    console.log(`Valor somado de 5: ${newValue + 5}`);
  });

Agora iremos tratar a promise caso fosse chamado o reject:

new Promise((resolve, reject) => {
  console.log('Inicio da Promise');
  const numero = 10;

  reject('Número não identificado');
})
  .then((value) => {
    console.log(`Primeiro valor: ${value}`);
    return value;
  })
  .then((newValue) => {
    console.log(`Valor somado de 5: ${newValue + 5}`);
  })
  .catch((error) => {
    console.log(`Houve um erro: ${error}`);
  });

Como fazemos a chamada de reject(), a função logo irá chamar o método .catch que também recebe um parâmetro e o mesmo é retornado no console.log(), renderizando:

Inicio da Promise
Houve um erro: Número não identificado

Um método muito utilizado, é a API fetch que realiza requisições HTTP através de Promises.

Todo List com React: passo a passo

Lucas Lomeu — Tue, 16 Nov 2021 23:36:56 +0000

Introdução

Nesse tutorial iremos desenvolver um "TodoList" em ReactJs da maneira mais simples possível, sendo assim, não iremos focar em estilização do mesmo. Recomendo que tenha noção básica de JavaScript.

Criando o projeto

Para iniciarmos o projeto, abra seu terminal e use o seguinte comando

npx create-react-app todolist

Após a criação, dirija-se até o diretório e abra seu VisualStudio Code

Limpando arquivos desnecessários

Para esse tutorial, poderemos remover alguns arquivos desnecessários de nossa aplicação.

Na pasta src, remova os arquivos:

App.test.js
index.css
logo.svg
reportWebVitals.js
setupTests.js

Você também deverá retirar a importação desses arquivos no App.js.

Parte 01

Logo de início deveremos fazer a importação do useState no App.js, pois estamos desenvolvendo um TodoList, ou seja, teremos alterações de estado (adição, remoção) de itens na lista de afazeres.

import { useState } from 'react';

Assim, estaremos aptos a utilizar o Hook.

Agora, deveremos criar o estado inicial da lista, para isso, utilizamos o useState, sendo um hook que retorna um array com dois valores, o primeiro é o estado atual e imutável, já o segundo uma função que irá alterar o estado do componente quando a mesma for ativada.

const [ todo, setTodo ] = useState([]);

-Todo representa o primeiro valor, logo o estado atual.
-setTodo representa o segundo valor, logo a função que irá realizar as alterações. (Por padrão costumamos nomear o segundo valor com "set" e logo após o nome dado ao primeiro valor).

O valor entre parenteses do useState representa o valor INICIAL do estado, como estamos criando uma lista de afazeres, o valor inicial é um Array que poderá conter vários itens.

Agora iremos criar outro estado para os novos itens a serem adicionados nesse array:

const [newTodo, setNewTodo] = useState('');

Dessa vez o estado inicial é uma string vazia, pois é o valor inicial do input do tipo texto que iremos inserir na nossa aplicação.

Parte 02

Com nossos estados criados, iremos desenvolver o que será renderizado, para isso adicionaremos um input.

function App() {
  const [todo, setTodo] = useState([]);
  const [newTodo, setNewTodo] = useState('');

  return (
    <>
      <h1>Todo List</h1>
      <input
        type="text"
        value={newTodo}
        onChange={(item) => setNewTodo(item.target.value)}
      />
    </>
  );
}

Para envolvermos várias tags HTML, podemos utilizar uma div ou então fragments <></> e todo o conteudo dentro do mesmo.

Criamos um input do tipo texto; no valor passamos o newTodo, sendo identico ao do estado já criado e onChange passamos uma função, onde conforme o estado é alterado, ele atualiza seu valor (value={newTodo}).

Ou seja, o valor (texto) atual presente no input criado, será adicionado ao nosso estado, com isso poderemos futuramente fazer com que esse valor seja renderizado na lista de afazeres.

Para que possamos adicionar esse valor em uma lista, iremos adicionar um botão que ao ser clicado, chamará a função addNewTodo:

function addNewTodo() {
    setTodo([...todo, newTodo]);
    setNewTodo('');
  }

Na primeira linha, chamamos a função do nosso primeiro estado, onde seu valor inicial é um array vazio e definimos agora que seu valor será tudo que estava presente nesse array antes (para isso utilizamos o spread), e no segundo parâmetro passamos o newTodo, ou seja, toda alteração que for feita nesse estado, após ser clicado no botão de "Adicionar", essa alteração/valor será adicionado ao nosso estado inicial da aplicação (todo).

Já na segunda linha, definimos que ao adicionar o novo valor no nosso estado, não podemos deixar o valor/texto do nosso input com o que foi digitado, devemos retirar tudo e transformar nosso estado inicial em uma string vazia novamente.

O botão a ser criado:

 <button onClick={() => addNewTodo()}>Adicionar</button>

Recapitulando: Ao ser clicado, chamará nossa função addNewTodo(), que irá adicionar o novo valor ao nosso estado atual e logo após resetar o valor escrito no input.

Parte 03

Agora iremos renderizar todos esses valores em uma lista, para isso utilizaremos o map.

<ul>
    {todo.map((item) => (
       <li>
         {item}
       </li>
    ))}
</ul>

Ou seja, a cada item/todo/valor novo adicionado ao nosso array de todos, o map irá percorrer essa lista de array e renderizar um por um em forma de lista. No código acima, passamos como parâmetro item, sendo assim, cada item presente no todo, será renderizado um a um, até que o ultimo seja renderizado.

Escrevemos o código entre chaves pra mostrar que se trata de um código javascript e não HTML.

Com isso, chegamos a uma tela semelhante a essa:

Parte 04

Assim como podemos adicionar itens/afazeres ao nosso array, podemos também excluir o mesmo.

Sendo assim, iremos criar dentro do map um botão para que seja renderizado a cada item.

<button onClick={() => removeTodo(index)}>Deletar</button>

Como podemos ver, ao ser clicado ele chama a função removeTodo que tem como parâmetro index. Esse parâmetro nós podemos identificar ele no próprio map, é o segundo valor a ser passado na função.

{todo.map((item, index) => (
   <li>
     {item}
   <button onClick={() => removeTodo(index)}>Deletar</button>
   </li>
 ))}

Deveremos passar esse parâmetro também na função, para que possamos identificar o item. Ele funciona como identificador único, ID

  function removeTodo(index) {
    let tmpArray = [...todo];
    tmpArray.splice(index, 1);
    setTodo(tmpArray);
  }

Criamos uma variável tmpArray, que define um array temporário, onde utilizamos o spread para adicionar tudo que contemos em nossa lista.

Utilizamos o splice e passamos como parâmetro o index (identificador único que utilizamos como parâmetro na função e que passamos ele no map) e definimos que ele irá retirar apenas um item a partir do index 1.

O método splice() altera o conteúdo de uma lista, adicionando novos elementos enquanto remove elementos antigos.

E para finalizar, definimos o novo valor do estado (setTodo), com o valor do nosso array temporário tmpArray, onde já foram feitas as modificações de exclusão de item.

Resultado da renderização

Código Final

import { useState } from 'react';

function App() {
  const [todo, setTodo] = useState([]);
  const [newTodo, setNewTodo] = useState('');

  function addNewTodo() {
    setTodo([...todo, newTodo]);
    setNewTodo('');
  }

  function removeTodo(index) {
    let tmpArray = [...todo];
    tmpArray.splice(index, 1);
    setTodo(tmpArray);
  }

  return (
    <>
      <h1>Todo List</h1>
      <input
        type="text"
        value={newTodo}
        onChange={(item) => setNewTodo(item.target.value)}
      />
      <button onClick={() => addNewTodo()}>Adicionar</button>
      <ul>
        {todo.map((item, index) => (
          <li>
            {item}
            <button onClick={() => removeTodo(index)}>Deletar</button>
          </li>
        ))}
      </ul>
    </>
  );
}

export default App;