Aprendendo Angular através de um diálogo

🧠 INVESTIGAÇÃO ADAPTATIVA

Dia 1 — Aprendendo Angular através de um diálogo

👨‍💼 João — Entrevistador

Olá, eu sou o João. Trabalho na empresa X e hoje vou conduzir uma entrevista técnica para uma vaga de Junior Frontend Developer.

Vamos começar com uma situação real.

Precisamos desenvolver uma aplicação para uma escola.

A aplicação deve permitir fazer login, listar estudantes, cadastrar, editar e remover estudantes. Os dados vêm de uma API REST.

Acabaste de criar o projeto Angular.

Como começarias a organizar essa aplicação?

👨‍💻 Matando Pedro — Candidato

Certo. Então a primeira coisa que eu vou fazer é criar a estrutura do projeto.

Vou instalar o Angular com npm, instalar a versão mais recente e o Angular já começa a definir toda a base do projeto, com services, components, HTML e toda essa estrutura inicial.

Depois vou fazer uma tela de login e cadastro.

Também vou criar a parte da API de estudantes.

Depois vou criar uma tela para listar os estudantes, um componente.

Outra tela para mostrar os detalhes do estudante.

E na lista vou colocar uma opção para eliminar o estudante.

Depois vou usar um Service para fazer...

👨‍💼 João

O que exatamente colocarias dentro desse Service?

Imagina que tens um "StudentListComponent" e precisas buscar os estudantes através de:

"GET /api/students"

Quem deveria fazer essa chamada HTTP: o componente ou o Service? E por quê?

👨‍💻 Matando Pedro

O Service.

Porque normalmente Service é algo compartilhado pela aplicação.

A chamada HTTP pode ser reutilizada em diferentes partes. Se eu colocasse no componente, teria que replicar esse código sempre que criasse outro componente.

👨‍💼 João

A ideia principal está correta.

Mas vamos refinar.

A razão principal não é simplesmente o Service ser compartilhado.

É separação de responsabilidades.

O componente deve preocupar-se principalmente com a interface e interação.

O Service pode encapsular a responsabilidade de obter e manipular os estudantes.

Então temos:

Component → Service → HttpClient → API

👨‍💼 João

Agora outra pergunta.

O Service deve conter toda a lógica da aplicação?

👨‍💻 Matando Pedro

Não necessariamente.

No Service podemos implementar helpers, providers HTTP e lógica de negócio.

Ele é muito bom para comunicação externa.

👨‍💼 João

Boa. Só precisamos fazer uma precisão.

Service não significa simplesmente “comunicação externa”.

Ele serve para encapsular uma responsabilidade que não deveria ficar diretamente no componente.

Comunicação com API é apenas um dos usos.

Agora temos outro problema.

A rota "/students" só pode ser acessada por usuários autenticados.

O que usarias?

👨‍💻 Matando Pedro

Usaria o recurso do Angular chamado Guard.

Ele vai proteger a rota e verificar se o acesso está autorizado.

👨‍💼 João

Exatamente.

Guard.

Agora aparece outro problema.

Todas as requisições precisam enviar o token:

"Authorization: Bearer "

Temos:

"GET /students"
"POST /students"
"PUT /students/1"
"DELETE /students/1"

Você colocaria o código do token dentro de cada método do Service?

👨‍💻 Matando Pedro

Não.

Criaria um... um base... alguma coisa que faça esse token.

👨‍💼 João

A ideia de centralizar está correta.

O recurso que procuramos é o HTTP Interceptor.

Ele pode interceptar as requisições HTTP e adicionar automaticamente o token.

Então agora temos:

Component
↓
Service
↓
HttpClient
↓
Interceptor
↓
API

---

👨‍💼 João

A API devolve:

"2005-03-15"

Mas queremos mostrar na tela:

"15/03/2005"

Você colocaria essa transformação dentro do Service?

👨‍💻 Matando Pedro

Aqui não me vem à mente...

Talvez usem Terraform?

👨‍💼 João

Boa. Não acertaste, e isso é exatamente o que queremos descobrir durante o estudo.

Aqui o recurso é o Pipe.

O Pipe é usado para transformar um valor na apresentação.

Por exemplo:

"{{ student.birthDate | date:'dd/MM/yyyy' }}"

Resultado:

15/03/2005

Então:

Service → responsabilidade e acesso aos dados.
Pipe → transformação para apresentação.
Component → interface e interação.

---

👨‍💼 João

Agora temos outro problema.

Na tela queremos mostrar:

João — Ativo
Maria — Inativo
Pedro — Ativo

Queremos aplicar uma classe CSS diferente dependendo do estado.

Ativo → verde.
Inativo → cinza.

Que recurso do Angular utilizarias?

👨‍💻 Matando Pedro

Podemos usar a directive "ngModel".

Ela permite colocar condições dentro do HTML para definir cores.

👨‍💼 João

Estás perto no conceito de Directive, mas confundiste dois recursos.

"ngModel" é usado principalmente para two-way data binding, especialmente em formulários.

Para alterar a aparência, podemos utilizar, por exemplo:

"[class.active]="student.active""

ou "ngClass".

Então aprendemos mais uma coisa:

Directive permite adicionar ou modificar comportamento de elementos no DOM.

E "ngModel" é uma directive relacionada principalmente ao binding de formulários.

---

👨‍💼 João

O projeto cresceu.

Temos:

"students/"
→ "student-list"
→ "student-detail"
→ "student-form"

"auth/"
→ "login"
→ "register"

Como organizarias e agruparias esses componentes no Angular?

E qual é a diferença entre NgModule e Standalone?

👨‍💻 Matando Pedro

Entre módulos, nós organizamos os componentes por módulos e depois vamos ter um módulo pai que vai chamar os children.

E carrega as rotas.

Isso facilita na eficiência de lazy loading e tudo isso.

Standalone, acho que é quando temos um único módulo pai que carrega todos os ficheiros.

👨‍💼 João

A primeira parte está no caminho certo.

No modelo tradicional, podemos agrupar funcionalidades através de "NgModule".

Por exemplo:

"StudentsModule"
→ "StudentListComponent"
→ "StudentDetailComponent"
→ "StudentFormComponent"

Mas há uma correção importante.

Standalone é praticamente o contrário daquilo que descreveste.

Um componente Standalone pode declarar diretamente as suas dependências sem precisar pertencer a um "NgModule".

---

👨‍💼 João

Você mencionou lazy loading.

Por que utilizaria lazy loading?

Temos:

"/"
"/login"
"/students"
"/reports"
"/admin"

Por que não simplesmente carregar tudo quando a aplicação começa?

👨‍💻 Matando Pedro

Porque à medida que o projeto vai crescer, vai ficar muito lento o Angular fazer um build e descarregar todo o projeto.

Isso pode matar a eficiência da aplicação.

👨‍💼 João

O raciocínio está correto.

Só precisamos fazer uma precisão.

O problema principal para o usuário não é o build ficar lento. O build acontece durante desenvolvimento ou CI.

O problema é o carregamento inicial da aplicação.

Sem lazy loading, o usuário pode acabar carregando recursos que ainda nem precisa.

Com lazy loading, partes da aplicação podem ser carregadas quando forem necessárias.

---

🧠 O que aconteceu nesta entrevista?

Nós não começámos decorando definições.

Começámos com um problema.

Uma resposta gerou uma nova pergunta.

A pergunta revelou uma lacuna.

A lacuna levou à investigação.

A investigação revelou o conceito.

E o conceito foi colocado diante de outro problema.

Problema → Hipótese → Pergunta → Investigação → Conceito → Aplicação → Transferência

Essa é a ideia por trás da Investigação Adaptativa.

«Aprender não precisa começar pela definição.

Às vezes, começa por uma pergunta que revela aquilo que ainda não sabemos.»