Pular para conteúdo

Desenvolvimento Frontend com Angular 💻

Domine a criação de aplicações web modernas com Angular, explorando desde a arquitetura clássica com NgModules até as inovações modernas com Standalone Components, RxJS e APIs REST.

Foco do Curso

Metodologia: Aprendizado prático focado na construção de Single Page Applications (SPA) de alta performance, seguindo as melhores práticas do mercado e do Google.

🎯 O Que Você Vai Aprender

  • Fundamentos e CLI --- Conheça o ecossistema Angular, instale o CLI e crie sua primeira aplicação SPA com a estrutura profissional. Ir para Módulo 1

  • Data Binding e Diretivas --- Domine a manipulação dinâmica de dados com Interpolação, Event Binding e Diretivas Estruturais como *ngIf e *ngFor. Ver Data Binding

  • Standalone Components --- Aprenda a nova forma de desenvolver com Angular 15+, eliminando a complexidade dos NgModules e otimizando o build. Ver Angular Moderno

  • RxJS e HTTP Client --- Consuma APIs de forma reativa, utilizando Observables, Pipes e o poderoso HttpClient para integrações robustas. Ver Reatividade

📚 Jornada de Aprendizado (16 Aulas)

O curso é estruturado para levar você do zero ao deploy profissional.

🧱 Módulo 1: Fundamentos e Estrutura (Aulas 01-04)

⚙️ Módulo 2: Core e Comunicação (Aulas 05-07)

🚀 Módulo 3: Angular Moderno (Aulas 08-11)

🏆 Módulo 4: Profissional e Deploy (Aulas 12-16)

Começar Minha Jornada Angular

Plano de Ensino 🧭

Curso: Desenvolvimento Frontend com Angular
Público-alvo: Estudantes de ADS, Ciência da Computação e Desenvolvedores de Software
Carga Horária: 20 Aulas (80 Horas Teórico-Práticas)

🎯 1. Objetivos do Curso

  • Compreender os fundamentos conceituais e arquiteturais de Desenvolvimento Frontend com Angular.
  • Aplicar padrões de projeto, sintaxe moderna e boas práticas da indústria.
  • Desenvolver soluções completas através de exercícios práticos e desafios de projeto.

📚 2. Cronograma de Aulas (Matriz de 20 Semanas)

Aula Tema Central Atividades e Entregas
01 Introdução ao Angular e Ecossistema ️ Teoria, Prática Guiada, Quiz e Exercícios
02 Estrutura do Projeto e Componentes (Abordagem Clássica) ️ Teoria, Prática Guiada, Quiz e Exercícios
03 Data Binding Teoria, Prática Guiada, Quiz e Exercícios
04 Diretivas Estruturais e de Atributo ️ Teoria, Prática Guiada, Quiz e Exercícios
05 Comunicação entre Componentes Teoria, Prática Guiada, Quiz e Exercícios
06 Serviços e Injeção de Dependência Teoria, Prática Guiada, Quiz e Exercícios
07 Roteamento (Abordagem Clássica) ️ Teoria, Prática Guiada, Quiz e Exercícios
08 Standalone Components Teoria, Prática Guiada, Quiz e Exercícios
09 Roteamento no Modelo Standalone ️ Teoria, Prática Guiada, Quiz e Exercícios
10 Formulários no Angular Teoria, Prática Guiada, Quiz e Exercícios
11 HTTP Client e Consumo de API REST Teoria, Prática Guiada, Quiz e Exercícios
12 RxJS e Programação Reativa Teoria, Prática Guiada, Quiz e Exercícios
13 Arquitetura e Organização Profissional ️ Teoria, Prática Guiada, Quiz e Exercícios
14 Estilização Moderna e Componentes de UI Teoria, Prática Guiada, Quiz e Exercícios
15 Build, Deploy e Performance Teoria, Prática Guiada, Quiz e Exercícios
16 Projeto Final Integrador Teoria, Prática Guiada, Quiz e Exercícios
17 Arquitetura com Standalone Components e Signals Teoria, Prática Guiada, Quiz e Exercícios
18 Injeção de Dependências Avançada e Scopes Teoria, Prática Guiada, Quiz e Exercícios
19 Formulários Reativos Avançados e Validadores Customizados Teoria, Prática Guiada, Quiz e Exercícios
20 Projeto Capstone: Aplicação Angular Autônoma de Alta Escala Teoria, Prática Guiada, Quiz e Exercícios

🧠 3. Metodologia de Ensino

  • Teoria Fundamentada: Aulas com conceitos detalhados, diagramas arquiteturais e sintaxe de referência.
  • Ciclo Teoria ⇄ Prática: Cada aula conta com Quiz Interativo (10 questões) para validação imediata, Lista de Exercícios Sanfonados (com Gabarito Explicado) e Desafio de Projeto Prático.
  • Laboratório Contínuo: Ambientes configurados passo a passo na seção de Setups da plataforma.

💼 4. Competências e Perfil Desenvolvido

  • Dominar as ferramentas e fluxos de desenvolvimento de Desenvolvimento Frontend com Angular.
  • Resolver problemas técnicos de alta complexidade com código limpo e performático.
  • Construir portfólio prático com 20 projetos aplicados.

📊 5. Critérios de Avaliação

  • 20 Listas de Exercícios: Resolução individual dividida em Básico, Intermediário e Desafio.
  • 20 Quizzes Interativos: Validação formativa com feedback imediato via JavaScript.
  • 20 Desafios de Projetos: Aplicações práticas consolidando o aprendizado de cada unidade.

Aulas

Aula 01: Introdução ao Angular e Ecossistema 🅰️

Nesta aula, vamos mergulhar no universo do Angular, entender o conceito de Single Page Applications (SPA) e preparar nosso ambiente para criar a primeira aplicação profissional.

🌐 O que é SPA (Single Page Application)?

Uma SPA é uma aplicação web que carrega apenas uma única página HTML e atualiza dinamicamente o conteúdo à medida que o usuário interage. Diferente dos sites tradicionais, não há recarregamento total da página (refresh).

Conceito Chave

Em uma SPA, a navegação entre visualizações ocorre no lado do cliente (browser), o que proporciona uma experiência de usuário muito mais fluida e rápida, similar a um aplicativo mobile.

🏛️ Arquitetura do Angular

O Angular segue uma arquitetura baseada em Componentes, onde cada parte da interface é uma peça independente.

graph TD
    A[Aplicação Angular] --> B[Componente Raiz]
    B --> C[Home Component]
    B --> D[Navbar Component]
    B --> E[Footer Component]
    C --> F[Card Component]
    C --> G[List Component]

🛠️ Preparando o Ambiente

Para começar, precisamos instalar o Node.js e o Angular CLI.

1. Instalação com Termynal

# Instalando o Angular CLI globalmente
$ npm install -g @angular/cli

# Verificando a instalação
$ ng version

🚀 Prática: Primeiro Projeto

Vamos criar e rodar nosso primeiro projeto Angular utilizando o terminal.

Dica de Produtividade

Use o comando ng new seguido pelo nome do projeto. O Angular CLI cuidará de toda a estrutura inicial para você.

# 1. Criar projeto
$ ng new meu-primeiro-angular

# 2. Entrar na pasta
$ cd meu-primeiro-angular

# 3. Executar o servidor
$ ng serve --open

📑 Estrutura do Projeto

Ao abrir o projeto no VS Code, você verá uma estrutura organizada:

  • src/: Onde fica o código fonte da aplicação.
  • app/: Contém os componentes e lógica principal.
  • assets/: Imagens e arquivos estáticos.
  • angular.json: Configurações globais do CLI.

Atenção

Não altere arquivos na pasta node_modules manualmente. Todas as dependências devem ser gerenciadas via package.json.

🏁 Mini-Projeto da Aula

Crie uma nova aplicação Angular chamada projeto-aula-01, execute-a no seu navegador e altere o texto "Hello" no arquivo app.component.html.

Aula 02: Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️

Nesta aula, vamos dissecar a anatomia de um projeto Angular e entender o coração do framework: os Componentes.

📁 Estrutura de Pastas Profissional

Um projeto Angular possui diversos arquivos de configuração. Vamos entender os principais:

  • main.ts: O ponto de entrada da aplicação. É aqui que o Angular inicia o módulo raiz.
  • index.html: A única página física da SPA. Contém a tag <app-root>.
  • angular.json: Configurações do CLI (scripts, estilos globais, caminhos).

🧩 O que é um Componente?

Um componente no Angular é composto por 4 elementos principais:

  1. Classe (.ts): Lógica e dados.
  2. Template (.html): Estrutura visual.
  3. Estilo (.css ou .scss): Design isolado.
  4. Teste (.spec.ts): Validação automatizada.
graph LR
    A[Componente] --> B[HTML/Template]
    A --> C[CSS/Estilos]
    A --> D[TS/Lógica]
    A --> E[Metadados/@Component]

🛠️ Criando Componentes com o CLI

Não criamos arquivos manualmente! Usamos o comando generate (ou o atalho g).

# Gerar um componente chamado 'cabecalho'
$ ng generate component cabecalho

# Atalho rápido
$ ng g c rodape

Comportamento do CLI

Ao gerar um componente, o CLI cria os 4 arquivos, cria uma pasta própria e, na abordagem clássica, o registra automaticamente no app.module.ts.

📦 Introdução ao NgModule

Na abordagem clássica, o Module é o arquivo que agrupa componentes, serviços e outras dependências.

Atenção

Para que um componente possa ser usado no HTML de outro, ele deve estar declarado em um NgModule.

🚀 Prática: Layout com Componentes

Vamos criar uma estrutura de layout simples com múltiplos componentes.

$ ng g c header
$ ng g c footer
$ ng g c content

No arquivo app.component.html, chame os seletores:

<app-header></app-header>
<app-content></app-content>
<app-footer></app-footer>

🏁 Mini-Projeto da Aula

Crie três componentes (Navbar, Sidebar e MainContent). Organize-os no app.component.html para formar o layout de um dashboard simples. Customize as cores de cada um usando arquivos CSS isolados.

Aula 03: Data Binding 📡

Nesta aula, vamos aprender como conectar a nossa lógica (TypeScript) com a nossa interface (HTML) usando o Data Binding.

🔄 O que é Data Binding?

Data Binding é a comunicação automática entre o código (.ts) e o template (.html). Existem quatro tipos principais:

graph TD
    A[Data Binding] --> B[Unidirecional: TS -> HTML]
    A --> C[Unidirecional: HTML -> TS]
    A --> D[Bidirecional: Ambos]

    B --> B1[Interpolação {{ }}]
    B --> B2[Property Binding [ ]]
    C --> C1[Event Binding ( )]
    D --> D1[Two-way Binding [( )]]

1. Interpolação {{ }}

Exibe valores de variáveis da classe diretamente no HTML.

// No arquivo .ts
nome = 'Angular';

<!-- No arquivo .html -->
<h1>Bem-vindo ao {{ nome }}!</h1>

2. Property Binding [ ]

Associa um valor da classe a uma propriedade de um elemento HTML (como src, disabled, href).

imagemUrl = 'assets/logo.png';
botaoDesabilitado = true;

<img [src]="imagemUrl">
<button [disabled]="botaoDesabilitado">Clique aqui</button>

3. Event Binding ( )

Escuta eventos do HTML (cliques, digitação) e executa funções na classe.

aoClicar() {
    alert('Botão clicado!');
}

<button (click)="aoClicar()">Enviar</button>

4. Two-Way Data Binding [(ngModel)]

Mantém o valor sincronizado em ambos os sentidos. Se mudar no HTML (input), muda na classe. Se mudar na classe, muda no HTML.

Importante

Para usar o ngModel, você precisa importar o FormsModule no seu módulo (ex: app.module.ts).

<input [(ngModel)]="usuario">
<p>Olá, {{ usuario }}!</p>

🏁 Mini-Projeto da Aula

Crie um formulário simples que contenha um campo de texto e um botão. Ao digitar no campo, o texto deve aparecer em tempo real logo abaixo (Two-way binding). Ao clicar no botão, o campo deve ser limpo (Event binding + Property binding).

Aula 04: Diretivas Estruturais e de Atributo 🛠️

Nesta aula, vamos aprender como manipular a estrutura do nosso HTML e o comportamento dos elementos usando as Diretivas do Angular.

🧩 O que são Diretivas?

Diretivas são instruções que o Angular usa para transformar o DOM. Elas se dividem em dois grandes grupos:

  1. Estruturais: Alteram a estrutura do HTML (adicionam ou removem elementos). Usam o prefixo *.
  2. De Atributo: Alteram a aparência ou o comportamento de um elemento existente.

🏗️ Diretivas Estruturais

As mais famosas são o *ngIf e o *ngFor.

1. *ngIf

Renderiza um elemento apenas se uma condição for verdadeira.

<!-- Se logado for true, exibe a mensagem -->
<p *ngIf="logado">Bem-vindo de volta!</p>

2. *ngFor

Cria um loop para repetir um elemento para cada item de uma lista.

<ul>
  <li *ngFor="let item of listaCategorias">
    {{ item }}
  </li>
</ul>

🎨 Diretivas de Atributo

Alteram como o elemento se parece.

1. ngClass

Adiciona ou remove classes CSS dinamicamente.

<!-- Adiciona a classe 'sucesso' se o status for 'ativo' -->
<div [ngClass]="{ 'sucesso': status === 'ativo' }">
  Status do Sistema
</div>

2. ngStyle

Aplica estilos CSS inline dinamicamente.

<p [ngStyle]="{ 'color': corSelecionada, 'font-size': '20px' }">
  Texto Colorido
</p>

🌟 Diagrama de Funcionamento

graph LR
    A[Componente] --> B{Diretiva}
    B -- Estrutural --> C[Muda o DOM: Adiciona/Remove]
    B -- Atributo --> D[Muda o Elemento: Cor/Classe]

🛠️ Criando uma Diretiva Personalizada (Intro)

Você também pode criar suas próprias diretivas para reutilizar comportamentos.

# Gerar uma diretiva
$ ng generate directive destaca-item

🚀 Prática: Listagem Dinâmica

Vamos criar uma lista de "Tarefas" onde podemos marcar como concluídas.

  1. Use *ngFor para listar as tarefas.
  2. Use *ngIf para mostrar um aviso se a lista estiver vazia.
  3. Use ngClass para riscar o texto da tarefa quando ela estiver concluída.

🏁 Mini-Projeto da Aula

Crie uma galeria de produtos. Cada produto deve ser um objeto com nome, preço e disponibilidade. Use *ngFor para exibir os produtos, *ngIf para mostrar o selo "Esgotado" e ngStyle para mudar a cor do preço (vermelho para produtos caros, verde para baratos).

Aula 05: Comunicação entre Componentes 🔄

Nesta aula, vamos aprender como os componentes "conversam" entre si em uma arquitetura hierárquica usando @Input e @Output.

📢 Fluxo de Dados Hierárquico

No Angular, os dados geralmente fluem do pai para o filho e os eventos do filho para o pai.

graph TD
    P[Componente Pai] -- "@Input" --> F[Componente Filho]
    F -- "@Output (EventEmitter)" --> P

📥 Recebendo Dados: @Input()

O decorator @Input() permite que o componente filho receba valores vindo de seu pai.

No Componente Filho (.ts):

import { Component, Input } from '@angular/core';

@Component({ ... })
export class FilhoComponent {
    @Input() mensagemDoPai: string = '';
}

No Componente Pai (.html):

<app-filho [mensagemDoPai]="'Olá, meu filho!'"></app-filho>

📤 Enviando Eventos: @Output()

O decorator @Output() combinado com EventEmitter permite que o filho envie notificações ou dados de volta para o pai.

No Componente Filho (.ts):

import { Component, Output, EventEmitter } from '@angular/core';

@Component({ ... })
export class FilhoComponent {
    @Output() eventoFilho = new EventEmitter<string>();

    notificarPai() {
        this.eventoFilho.emit('Oi, Pai! Eu mudei.');
    }
}

No Componente Pai (.html):

<!-- Escutando o evento (eventoFilho) -->
<app-filho (eventoFilho)="receberNotificacao($event)"></app-filho>

🧠 Smart vs Dumb Components

  • Smart Components (Pai): Gerenciam dados, fazem chamadas de API e cuidam da lógica de negócio.
  • Dumb Components (Filho): Apenas exibem dados recebidos via @Input e notificam o pai via @Output. São altamente reutilizáveis.

🚀 Prática: Lista de Contatos

Vamos construir um sistema onde: 1. O Pai gerencia uma lista de contatos. 2. O Filho exibe o detalhe de um único contato (@Input). 3. O Filho tem um botão "Excluir" que notifica o pai para remover aquele contato da lista (@Output).

🏁 Mini-Projeto da Aula

Crie um componente Contador. O componente pai deve passar o valor inicial do contador para o filho. O filho deve ter botões de "+" e "-". Toda vez que o valor mudar no filho, ele deve emitir um evento para o pai atualizar o total geral na tela dele.

Aula 06: Serviços e Injeção de Dependência 💉

Nesta aula, vamos aprender como compartilhar lógica e dados entre componentes de forma profissional e escalável usando Serviços e o sistema de Injeção de Dependência (DI) do Angular.

🏛️ Por que usar Serviços?

Componentes devem focar na interface (UI). Lógica pesada, como cálculos ou chamadas a banco de dados, deve ser isolada em um Serviço.

  • Reaproveitamento: Vários componentes podem usar o mesmo serviço.
  • Singleton: Por padrão, o Angular cria apenas uma instância do serviço para toda a aplicação.
  • Organização: Separa a "casca" (UI) do "motor" (Lógica).

🛠️ Criando um Serviço com o CLI

Usamos o comando generate service (ou g s).

# Gerar um serviço de autenticação
$ ng generate service auth/auth

# Atalho rápido
$ ng g s data

💉 Injeção de Dependência

Não instanciamos servicos com new Servico(). O Angular faz isso para nós através do Construtor.

1. Definindo o Serviço:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root' // Singleton: disponível em toda a app
})
export class DadosService {
  lista: string[] = ['Angular', 'React', 'Vue'];

  getDados() {
    return this.lista;
  }
}

2. Injetando no Componente:

export class ListaComponent {
  // O Angular injeta automaticamente a instância
  constructor(private service: DadosService) {}

  minhaLista = this.service.getDados();
}

🌟 Diagrama de Injeção

graph TD
    S[Serviço] --> |Injetado| C1[Home Component]
    S --> |Injetado| C2[Navbar Component]
    S --> |Injetado| C3[Dashboard Component]
    C1 -.-> |Compartilha Dados| S
    C3 -.-> |Compartilha Dados| S

🚀 Prática: Gerenciamento de Tarefas

Vamos refatorar nosso código de tarefas para que: 1. A lista de tarefas não fique mais no componente. 2. Crie um TarefaService com métodos adicionar() e listar(). 3. Dois componentes diferentes usem o mesmo serviço para mostrar a mesma lista.

🏁 Mini-Projeto da Aula

Crie um CarrinhoService. Ele deve ter um array privado de itens. Crie métodos para adicionarItem(produto) e exibirTotal(). Use esse serviço em um componente de "Lista de Produtos" e em um componente de "Mini-Carrinho" (que fica no topo da página).

Aula 07: Roteamento (Abordagem Clássica) 🛣️

Nesta aula, vamos aprender como transformar nossa Single Page Application em um site multipágina usando o Angular Router.

📍 O que é o Roteamento?

O roteamento permite que o usuário navegue entre diferentes visualizações (URL /home, /contato) sem que o navegador faça um "refresh" total.

graph LR
    URL[URL do Browser] --> R[Router]
    R --> |/home| C1[HomeComponent]
    R --> |/produtos| C2[ProdutosComponent]
    R --> |/vazio| C3[NotFoundComponent]

🛠️ Configuração Básica (app-routing.module.ts)

Na abordagem clássica, definimos um array de rotas.

const routes: Routes = [
  { path: 'home', component: HomeComponent },
  { path: 'produtos', component: ProdutosComponent },
  { path: '', redirectTo: '/home', pathMatch: 'full' } // Rota padrão
];

🏠 Exibindo as Rotas: router-outlet

Para indicar ao Angular onde os componentes das rotas serão renderizados, usamos a tag <router-outlet>.

<!-- app.component.html -->
<nav>...</nav>

<router-outlet></router-outlet> <!-- Componentes mudam aqui -->

<footer>...</footer>

Não usamos href para links internos! Usamos a diretiva routerLink para que o Angular controle a navegação.

<a routerLink="/home">Início</a>
<a [routerLink]="['/produtos', id]">Ver Produto</a>

🆔 Parâmetros de Rota

Podemos passar valores dinâmicos na URL (ex: /produto/123).

  1. Definição: { path: 'produto/:id', component: DetalheComponent }
  2. Captura: Usamos o serviço ActivatedRoute para ler o ID.

🚀 Prática: Site Institucional

Vamos criar um site com 3 páginas: 1. Home: Boas-vindas. 2. Sobre: Descrição da empresa. 3. Contato: Um formulário de contato.

Adicione um menu de navegação que permita transitar entre elas sem recarregar o browser.

🏁 Mini-Projeto da Aula

Crie um catálogo de filmes. Teremos duas rotas: /filmes (lista todos) e /filme/:id (mostra o detalhe do filme clicado). No componente de detalhe, exiba o ID recebido da URL para confirmar que o roteamento está funcionando.

Aula 08: Standalone Components 📦

Nesta aula, entramos na era do Angular Moderno. Vamos aprender como criar componentes que não precisam mais de um NgModule para funcionar.

🆕 O que mudou no Angular 15+?

Historicamente, todo componente precisava estar declarado em um módulo. Com os Standalone Components, o componente se torna autossuficiente.

graph LR
    A[Componente Clássico] --> B[NgModule]
    B --> C[Aplicação]

    D[Componente Standalone] --> E[Aplicação]
    D -.-> |Importa diretamente| F[CommonModule/Outros]

🛠️ Anatomia de um Standalone Component

A principal diferença está no decorator @Component, onde adicionamos a propriedade standalone: true.

@Component({
  selector: 'app-perfil',
  standalone: true, // A mágica acontece aqui!
  imports: [CommonModule, MeusOutrosComponents], // Importa o que precisa
  templateUrl: './perfil.component.html'
})
export class PerfilComponent {}

🚀 Iniciando a App sem Módulo

No Angular Moderno, o bootstrap da aplicação muda do módulo para o componente raiz diretamente usando bootstrapApplication.

Arquivo main.ts:

import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent)
  .catch(err => console.error(err));

⚖️ Comparação: Clássico vs Standalone

Característica Clássico (NgModule) Standalone (Moderno)
Declaração Obrigatória no Module Nenhuma (auto-gerido)
Imports Feito no Module Feito no próprio Componente
Complexidade Alta (muitos arquivos) Baixa (mais direto)
Performance Padrão Melhor (Tree-shaking)

🛠️ Gerando no CLI

# Gerar um componente standalone
$ ng generate component meu-comp --standalone

Dica

A partir de versões mais recentes, o Angular CLI pode ser configurado para que todos os componentes novos sejam standalone por padrão.

🚀 Prática: Primeiro Projeto Moderno

  1. Crie um novo componente usando a flag --standalone.
  2. Tente importar o CommonModule dentro dele para usar o *ngIf e o *ngFor.
  3. Note que você não precisou tocar no arquivo app.module.ts!

🏁 Mini-Projeto da Aula

Refatore seu projeto da Aula 02 (que usava módulos) para usar apenas Standalone Components. Remova o arquivo app.module.ts e atualize o main.ts para usar o bootstrapApplication.

Aula 09: Roteamento no Modelo Standalone 🗺️

Nesta aula, vamos aprender como configurar a navegação da nossa aplicação Angular usando o modelo moderno, eliminando a dependência do AppRoutingModule.

📍 Roteamento sem Módulos

No modelo standalone, não usamos mais o RouterModule.forRoot(). Em vez disso, usamos a função provideRouter() durante o bootstrap da aplicação.

Configuração no main.ts:

import { bootstrapApplication } from '@angular/platform-browser';
import { provideRouter } from '@angular/router';
import { routes } from './app/app.routes';

bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(routes) // Configura as rotas aqui!
  ]
});

📁 Organização de Rotas (app.routes.ts)

As rotas continuam sendo um array de objetos, mas agora importamos os componentes diretamente.

export const routes: Routes = [
  { path: 'home', component: HomeComponent },
  { path: 'login', component: LoginComponent }
];

🚀 Lazy Loading com loadComponent

No modelo clássico, o lazy loading era feito por módulos (loadChildren). No modelo standalone, podemos carregar componentes individuais sob demanda.

{
  path: 'dashboard',
  loadComponent: () => import('./features/dashboard.component')
    .then(m => m.DashboardComponent)
}

🛠️ O que mudou no HTML?

Absolutamente nada! As diretivas <router-outlet> e [routerLink] continuam funcionando da mesma forma.

Atenção

Como seu componente agora é Standalone, você deve importar explicitamente o RouterModule (ou as diretivas individuais como RouterOutlet) dentro do array imports do seu componente.

@Component({
  standalone: true,
  imports: [RouterOutlet, RouterLink], // Obrigatório importar!
  ...
})

🌟 Vantagens do Roteamento Standalone

  1. Menos arquivos: Não precisa do app-routing.module.ts.
  2. Performance: O Lazy Loading de componentes é mais granular que o de módulos.
  3. Clareza: O main.ts mostra claramente quais serviços e configurações a app possui.

🚀 Prática: Refatoração de Rotas

Vamos pegar o projeto da Aula 07 e: 1. Remover o AppRoutingModule. 2. Mover a constante routes para um arquivo próprio. 3. Configurar o provideRouter no main.ts. 4. Transformar o lazy loading de módulos em lazy loading de componentes.

🏁 Mini-Projeto da Aula

Crie um sistema de abas (Tabs). Cada aba deve ser um componente independente. Configure o roteamento para que cada aba tenha sua própria URL e use o loadComponent para que o código de cada aba só seja baixado quando o usuário clicar nela.

Aula 10: Formulários no Angular 📝

Nesta aula, vamos aprender como coletar e validar dados dos usuários usando as duas abordagens do Angular: Template-driven e Reactive Forms.

🎭 As Duas Abordagens

Característica Template-driven Reactive Forms
Configuração No HTML (Directivas) No TypeScript (Código)
Escalabilidade Indicado para formulários simples Indicado para formulários complexos
Validação No HTML Programática
Previsibilidade Menor (Assíncrono) Maior (Síncrono/Imutável)

1. Template-driven Forms

Usa o ngModel para criar o modelo de dados automaticamente a partir do HTML.

<form #meuForm="ngForm" (ngSubmit)="enviar(meuForm)">
  <input name="email" ngModel required email>
  <button [disabled]="meuForm.invalid">Enviar</button>
</form>

2. Reactive Forms

Você cria e gerencia o estado do formulário explicitamente no TypeScript. Oferece muito mais controle.

No TypeScript (.ts):

import { FormGroup, FormControl, Validators } from '@angular/forms';

meuForm = new FormGroup({
    nome: new FormControl('', [Validators.required]),
    email: new FormControl('', [Validators.required, Validators.email])
});

onSubmit() {
    console.log(this.meuForm.value);
}

No HTML (.html):

<form [formGroup]="meuForm" (ngSubmit)="onSubmit()">
  <input formControlName="nome">
  <input formControlName="email">
  <button type="submit">Cadastrar</button>
</form>

✅ Validações e feedback

O Angular permite verificar o estado de cada campo (dirty, touched, valid, invalid).

<div *ngIf="meuForm.get('email')?.invalid && meuForm.get('email')?.touched">
  Email é obrigatório e deve ser válido.
</div>

🌟 Ciclo do Formulário

graph LR
    A[Usuário Digita] --> B[Estado do Control Muda]
    B --> C{Válido?}
    C -- Sim --> D[Botão Ativado]
    C -- Não --> E[Exibe Erro]
    D --> F[Submit: Dados para o Servidor]

🚀 Prática: Cadastro de Usuário

Vamos construir um formulário de cadastro com: 1. Campos: Nome, Email, Senha e Confirmação de Senha. 2. Validação de obrigatoriedade e máscara de email. 3. Desabilitar o botão de enviar até que tudo esteja correto.

🏁 Mini-Projeto da Aula

Crie um formulário de Feedback. O usuário deve avaliar o serviço de 1 a 5 (Dropdown) e escrever um comentário (Textarea). Use Reactive Forms e exiba uma mensagem de sucesso na tela após o "envio" dos dados.

Aula 11: HTTP Client e Consumo de API REST 🌐

Nesta aula, vamos aprender como conectar nossa aplicação Angular a servidores externos para buscar, criar, atualizar e deletar dados usando o HttpClient.

📡 O que é o HttpClient?

É um serviço nativo do Angular que facilita a realização de requisições HTTP (GET, POST, PUT, DELETE) para APIs REST.

  • Baseado em Observables (RxJS).
  • Trata automaticamente a conversão para JSON.
  • Oferece interceptores para gerenciar tokens e erros.

🛠️ Configuração Standalone

No modelo standalone, habilitamos o cliente HTTP no main.ts usando o provider provideHttpClient().

import { bootstrapApplication } from '@angular/platform-browser';
import { provideHttpClient } from '@angular/common/http';

bootstrapApplication(AppComponent, {
  providers: [
    provideHttpClient() // Ativa o HTTP na app
  ]
});

💉 Usando o HttpClient no Serviço

Sempre isolamos as chamadas de API em serviços para manter o código limpo e reutilizável.

import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PostService {
  private url = 'https://jsonplaceholder.typicode.com/posts';

  constructor(private http: HttpClient) {}

  listarPosts() {
    return this.http.get<any[]>(this.url);
  }

  salvarPost(post: any) {
    return this.http.post(this.url, post);
  }
}

📥 Consumindo no Componente

Como o http.get retorna um Observable, precisamos usar o método .subscribe() para receber os dados.

export class ListaPostsComponent {
  posts: any[] = [];

  constructor(private service: PostService) {}

  ngOnInit() {
    this.service.listarPosts().subscribe(dados => {
      this.posts = dados;
    });
  }
}

🌟 Fluxo da Requisição

graph LR
    A[Componente] --> B[Serviço]
    B --> |http.get| C[API REST]
    C --> |JSON Response| B
    B --> |Observable| A
    A --> |subscribe| D[Atualiza Tela]

🚀 Prática: Consumo de API Real

Vamos utilizar a API gratuita JSONPlaceholder para: 1. Listar uma série de postagens em uma lista. 2. Criar um pequeno formulário para "simular" o envio de um novo post. 3. Implementar um botão de deletar que remove o item da interface.

🏁 Mini-Projeto da Aula

Crie um buscador de CEP usando a API do ViaCEP. O usuário digita o CEP, clica no botão e o seu serviço deve retornar o endereço completo para ser exibido na tela.

Aula 12: RxJS e Programação Reativa ⚡

Nesta aula, vamos entender o motor por trás do Angular: a biblioteca RxJS. Vamos aprender a lidar com fluxos de dados assíncronos de forma elegante e poderosa.

🌊 O que são Observables?

Pense em um Observable como um "fluxo de água" (dados). Você (Observer) pode colocar um balde (subscribe) para receber esses dados à medida que eles chegam.

  • Observable: A fonte dos dados.
  • Subscribe: A ação de começar a ouvir os dados.
  • Operator: Uma ferramenta para transformar o dado antes que ele chegue no balde.

🛠️ Operadores: O canivete suíço

O método .pipe() é usado para encadear operadores que modificam o fluxo de dados.

Principais Operadores:

  1. map: Transforma cada dado que passa (ex: mudar o nome para maiúsculo).
  2. filter: Deixa passar apenas os dados que atendem a uma condição.
  3. switchMap: Cancela a requisição anterior e inicia uma nova (ideal para buscas em tempo real).
  4. tap: Permite "espiar" o dado para fazer um log, sem alterá-lo.
this.http.get<any[]>(url).pipe(
  map(posts => posts.filter(p => p.id < 10)),
  tap(posts => console.log('Posts filtrados:', posts))
).subscribe();

🎯 Subjects e BehaviorSubjects

São tipos especiais de Observables que permitem enviar dados manualmente.

  • Subject: Envia dados apenas para quem já está inscrito.
  • BehaviorSubject: Guarda o último valor emitido. Novos inscritos recebem o valor atual imediatamente.

🚀 Async Pipe (Boas Práticas)

No Angular, a melhor forma de consumir um Observable no HTML é o Async Pipe (| async). Ele faz o subscribe e unsubscribe automaticamente para você, evitando vazamentos de memória (memory leaks).

<ul>
  <li *ngFor="let item of (itens$ | async)">
    {{ item.nome }}
  </li>
</ul>

🌟 Diagrama RxJS

graph LR
    Source[Fonte: API/Click] --> Pipe[Pipe: Transformação]
    Pipe --> Op1[map]
    Op1 --> Op2[filter]
    Op2 --> Sub[Subscriber: Tela]

🚀 Prática: Busca Reativa

Vamos criar um campo de busca que: 1. Espera o usuário parar de digitar (debounceTime). 2. Não faz buscas repetidas (distinctUntilChanged). 3. Cancela buscas antigas se uma nova começar (switchMap).

🏁 Mini-Projeto da Aula

Crie um serviço de Notificações Global usando um BehaviorSubject. Qualquer componente da aplicação deve ser capaz de chamar enviarMensagem(texto) e um componente de "Alert" (que usa o Async Pipe) deve exibir essa mensagem automaticamente.

Aula 13: Arquitetura e Organização Profissional 🏗️

Nesta aula, vamos aprender como estruturar projetos Angular de grande escala seguindo os padrões utilizados pelas maiores empresas de tecnologia.

📁 Padrão LIFT

O Angular recomenda o padrão LIFT: * Locate: Localizar o código rapidamente. * Identify: Identificar o que o arquivo faz pelo nome. * Flat: Manter uma estrutura o mais plana possível (sem pastas infinitas). * Try to be DRY: Evite repetições desnecessárias.

🏛️ Estrutura de Pastas Recomendada

Um projeto profissional geralmente divide as responsabilidades em três pilares:

  1. Core: Serviços globais, interceptores e guards (singleton).
  2. Shared: Componentes visuais genéricos (botões, inputs), pipes e diretivas reutilizáveis.
  3. Features: As funcionalidades do negócio (ex: login, vendas, perfil).
graph TD
    App[src/app] --> Core[core/]
    App --> Shared[shared/]
    App --> Features[features/]
    Features --> Login[login/]
    Features --> Products[products/]

🏷️ Convenções de Nomeclatura

O Angular CLI segue o padrão de kebab-case com sufixos descritivos: * usuario-header.component.ts * auth.service.ts * valida-email.directive.ts

Dica de Ouro

Mantenha cada arquivo com uma única responsabilidade (Single Responsibility Principle). Se um componente tem 1000 linhas, ele deve ser quebrado!

📦 Barrel Files (index.ts)

Para evitar dezenas de linhas de import no topo dos arquivos, usamos arquivos index.ts que exportam tudo de uma pasta.

// features/products/index.ts
export * from './product-list.component';
export * from './product-detail.component';
export * from './product.service';

🧱 Smart vs Dumb (Revisited)

Em arquiteturas profissionais: * Smart Components ficam na pasta features/. * Dumb Components ficam na pasta shared/ ou dentro da pasta de uma feature específica se não forem genéricos.

🚀 Prática: Refatoração de Arquitetura

Vamos reorganizar nosso projeto bagunçado! 1. Crie as pastas core, shared e features. 2. Mova os serviços de autenticação para core. 3. Crie um componente de botão estilizado dentro de shared. 4. Organize as páginas existentes dentro de features.

🏁 Mini-Projeto da Aula

Desenhe um diagrama de pastas para um sistema de E-commerce que contenha: Autenticação, Catálogo, Carrinho e Perfil do Usuário. Aplique os conceitos de Core, Shared e Features.

Aula 14: Estilização Moderna e Componentes de UI 🎨

Nesta aula, vamos aprender como deixar nossa aplicação Angular bonita, profissional e responsiva, explorando o CSS isolado e as bibliotecas de componentes.

👗 Estilização Isolada (View Encapsulation)

Por padrão, o CSS que você escreve em um componente não vaza para o resto da aplicação. O Angular adiciona atributos únicos ao HTML para garantir esse isolamento.

Tipos de Encapsulamento

  • Emulated (Padrão): Simula o isolamento via atributos.
  • None: O CSS se torna global.
  • ShadowDom: Usa a tecnologia nativa do browser para isolamento total.

📦 Bibliotecas de Componentes

Não precisamos reinventar a roda. Podemos usar bibliotecas que já trazem botões, modais e tabelas prontas.

  1. Angular Material: A biblioteca oficial seguindo o Material Design.
  2. PrimeNG: Uma das mais completas, com centenas de componentes.
  3. Tailwind CSS: Uma abordagem baseada em classes utilitárias que está dominando o mercado.

🛠️ Instalando Angular Material

# Adicionando o Material ao projeto
$ ng add @angular/material

Após instalado, basta importar os módulos (ou diretivas standalone) que deseja usar:

import { MatButtonModule } from '@angular/material/button';

@Component({
  standalone: true,
  imports: [MatButtonModule],
  template: `<button mat-raised-button color="primary">Click</button>`
})

🌓 Variáveis CSS e Temas

Use variáveis CSS (--cor-primaria) para facilitar a criação de temas (Light/Dark Mode).

:root {
  --primary-color: #3f51b5;
}

.meu-card {
  background-color: var(--primary-color);
}

🌟 Animações no Angular

O Angular possui um módulo potente para animações de transição de estados.

graph LR
    A[Estado: Inicial] --> |Transição| B[Estado: Final]
    B --> |Trigger| C[Animação na Tela]

🚀 Prática: Interface Premium

Vamos transformar nossa listagem de produtos simples em uma vitrine de luxo: 1. Instale o Angular Material. 2. Use o MatCard para exibir os itens. 3. Adicione um MatToolbar como cabeçalho. 4. Implemente um botão que abre um MatDialog (modal) para ver mais detalhes.

🏁 Mini-Projeto da Aula

Crie uma página de perfil de usuário "Dark Mode" usando apenas variáveis CSS. O usuário deve conseguir alternar entre o tema claro e escuro clicando em um botão que altera uma classe no body da aplicação.

Aula 15: Build, Deploy e Performance 🚀

Nesta aula, vamos aprender como preparar nossa aplicação para o mundo real, otimizando o tamanho do código e publicando o site na internet.

🏗️ O Processo de Build

Quando desenvolvemos, usamos o ng serve. Para produção, precisamos gerar arquivos estáticos (HTML/JS/CSS) otimizados usando o comando build.

# Gerar arquivos para produção
$ ng build

Os arquivos serão gerados na pasta dist/nome-do-projeto.

🌍 Gerenciando Ambientes

Você pode ter configurações diferentes para desenvolvimento e produção (ex: URLs de API). No Angular moderno, usamos as configurações de fileReplacements no angular.json ou arquivos de variáveis de ambiente.

Exemplo de Uso

environment.ts (Dev) vs environment.prod.ts (Produção).

🚀 Deploy no GitHub Pages

Uma das formas mais fáceis de hospedar seu projeto Angular gratuitamente.

# 1. Instale o utilitário
$ npm install -g angular-cli-ghpages

# 2. Faça o build
$ ng build --base-href "https://seu-usuario.github.io/nome-do-repo/"

# 3. Publique
$ npx angular-cli-ghpages --dir=dist/nome-do-projeto

⚡ Performance: Lighthouse

Devemos sempre verificar se nosso site está rápido e acessível. O Lighthouse (no Chrome DevTools) analisa: * Performance (tempo de carregamento). * Acessibilidade (uso de leitores de tela). * Melhores Práticas. * SEO.

🌟 Estratégias de Otimização

  1. Lazy Loading: Já vimos que carregar por demanda reduz o bundle inicial.
  2. Budget: O Angular permite definir alertas se o arquivo JS ficar grande demais.
  3. Images: Use formatos modernos (WebP) e carregamento ocioso (lazy).

🚀 Prática: Deploy da Nossa App

Vamos realizar o ciclo completo: 1. Criar os arquivos de ambiente. 2. Executar o build de produção. 3. Publicar no GitHub Pages (ou simular com um servidor local). 4. Rodar um relatório do Lighthouse e ajustar o que for necessário.

🏁 Mini-Projeto da Aula

Configure as "budgets" no seu arquivo angular.json para emitir um aviso se o pacote principal (main bundle) ultrapassar 1MB. Tente identificar qual parte da sua aplicação (ex: ícones ou bibliotecas pesadas) está consumindo mais espaço.

Aula 16: Projeto Final Integrador 🏆

Chegamos ao fim da nossa jornada! Esta aula é dedicada à consolidação de todo o conhecimento que adquirimos, através do desenvolvimento de uma aplicação completa do zero ao deploy.

📝 O Desafio Final

Você deverá construir um Gerenciador de Filmes/Séries Personalizado utilizando todas as tecnologias estudadas.

Requisitos Técnicos:

  1. Arquitetura: Uso obrigatório de Standalone Components e estrutura de pastas Core/Shared/Features.
  2. Roteamento: Navegação entre Listagem, Detalhes e Cadastro.
  3. Comunicação: Uso de @Input e @Output para criar componentes reutilizáveis (cards e botões).
  4. Serviços e HTTP: Consumir a API do TMDB ou simular com JSON Server.
  5. Formulários: Criar um formulário reativo para "Adicionar aos Favoritos" ou "Avaliar Filme".
  6. RxJS: Implementar uma busca em tempo real com operadores de filtragem e cancelamento.
  7. Estilização: Uso de Angular Material ou Tailwind CSS para uma interface moderna.

🗺️ Mapa de Competências

mindmap
  root((Angular Course))
    Fundamentos
      Componentes
      Módulos vs Standalone
      Data Binding
    Lógica Profissional
      Services
      DI
      HTTP Client
    Reatividade
      RxJS
      Observables
      Async Pipe
    Entrega
      Build
      Performance
      Deploy

🚀 Dicas para o Sucesso

  • Planeje antes: Desenhe as telas e o fluxo de dados no papel ou em uma ferramenta como o Figma.
  • Commit constante: Use o Git para salvar seu progresso passo a passo.
  • Documente: No README do seu projeto final, explique como rodá-lo e quais foram os maiores desafios.

🎁 Próximos Passos na Carreira

Parabéns! Você agora domina o Angular. O que estudar a seguir? * Signals: A novidade que está mudando a reatividade no Angular. * SSR (Server Side Rendering): Usando Angular Universal para SEO. * NGRX: Para gerenciamento de estado global em apps gigantescas.

🏁 Encerramento

Foi um prazer acompanhar você nesta trilha. O mercado de Frontend está sempre evoluindo, e com as bases sólidas que você construiu aqui, o sucesso é apenas uma questão de prática e dedicação.

Boa sorte com seu Projeto Final! 🚀

Aula 17 - Arquitetura com Standalone Components e Signals 🚦

Objetivo Pedagógico

Objetivo: Construção de aplicações Angular modernas baseadas em Standalone Components sem NgModules e reatividade granular orientada a Signals.

📑 1. Fundamentos Teóricos & Análise Técnica

O ecossistema Angular passou por sua maior transformação estrutural com a consolidação dos Standalone Components e o motor de reatividade Signals. Historicamente, o Angular dependia do conceito de NgModule para declarar dependências, diretivas e serviços de compilação. Essa abordagem adicionava alto nível de boilerplate e dificultava o tree-shaking e a modularização limpa.

Com os Standalone Components (standalone: true): 1. Cada componente declara diretamente no seu decorador @Component as dependências de template necessárias no array imports. 2. A aplicação pode ser inicializada via bootstrapApplication() a partir de uma função simplificada, sem módulo raiz.

Em conjunto, a introdução dos Angular Signals (baseados nas primitivas signal(), computed() e effect()) resolve o custo de desempenho da biblioteca Zone.js. Em vez de disparar uma checagem de detecção de mudanças (dirty checking) de cima a baixo na árvore inteira de componentes a cada evento assíncrono, os Signals permitem que o Angular saiba com precisão cirúrgica qual nó do DOM depende de qual valor reativo, permitindo a arquitetura Zoneless.

📐 Arquitetura Conceitual & Diagrama de Fluxo

flowchart TD
    subgraph ZoneJS ["Detecção Legada (Zone.js)"]
        Event["Evento / Timer"] --> RootCheck["Check Componente Raiz"]
        RootCheck --> C1["Check Filho 1"]
        RootCheck --> C2["Check Filho 2"]
        C2 --> C3["Check Neto 1 (Dirty Checking Global)"]
    end
    subgraph Signals ["Reatividade Granular (Signals)"]
        Sig["signal.set(novoValor)"] --> DirectDOM["Atualização Direta do Nó DOM Vinculado!"]
    end
    style ZoneJS fill:#ffebee,stroke:#c62828
    style Signals fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Eliminação de NgModules: Arquitetura direta, concisa e orientada a componentes independentes. - Detecção de Mudanças Cirúrgica: Atualização reativa apenas dos nós inscritos, abrindo caminho para o modo Zoneless. - Sinal Computado (computed): Valores derivados puros com memoização automática que só recalculam quando suas dependências mudam. - Interoperabilidade com RxJS: Uso de toSignal() e toObservable() para transitar suavemente entre fluxos reativos.

🛠️ 2. Implementação Prática em Angular 17+ e Signals

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// counter.component.ts (Standalone Component com Signals)
import { Component, signal, computed, effect } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-counter',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div class="counter-container">
      <h2>Contador Reativo: {{ count() }}</h2>
      <p>Dobro do Valor (Computado): {{ doubleCount() }}</p>
      <div class="actions">
        <button (click)="increment()">Incrementar (+1)</button>
        <button (click)="reset()">Zerar</button>
      </div>
    </div>
  `
})
export class CounterComponent {
  // 1. Sinal Writable
  readonly count = signal<number>(0);

  // 2. Sinal Derivado Computado (Memoizado)
  readonly doubleCount = computed(() => this.count() * 2);

  constructor() {
    // 3. Efeito colateral reativo
    effect(() => {
      console.log(`[Efeito] O valor atual do contador é: ${this.count()}`);
    });
  }

  increment(): void {
    this.count.update(value => value + 1);
  }

  reset(): void {
    this.count.set(0);
  }
}

💡 Análise Passo a Passo do Código

  1. Declaração Standalone: standalone: true elimina a necessidade de registrar o componente em arquivos app.module.ts.
  2. Sinal Escrita e Atualização: count.update(v => v + 1) altera o estado de forma atômica e avisa aos dependentes.
  3. Memoização com Computed: doubleCount só recalcula a multiplicação quando o valor de count() sofre mutação.

🎯 3. Próximos Passos & Sequência Didática

Aula 18 - Injeção de Dependências Avançada e Scopes 💉

Objetivo Pedagógico

Objetivo: Domínio do sistema de Injeção de Dependências (DI) hierárquica do Angular, provedores customizados, função inject() e resolução de scopes.

📑 1. Fundamentos Teóricos & Análise Técnica

O sistema de Injeção de Dependências (DI) do Angular é uma das mais avançadas implementações do princípio de Inversão de Controle (IoC) no desenvolvimento frontend. Diferente de frameworks que utilizam escopos globais simples, o Angular implementa um sistema de Injetores Hierárquicos, permitindo que dependências sejam isoladas por módulo, rota ou instância de componente.

A hierarquia de injetores é estruturada em duas árvores paralelas: 1. Árvore de Injetores de Ambiente (EnvironmentInjector): Provê serviços globais (providedIn: 'root') ou restritos a rotas específicas com providers: [...] no roteador. 2. Árvore de Injetores de Elementos (ElementInjector): Criada implicitamente para cada componente ou diretiva com a propriedade providers: [...] ou viewProviders: [...].

Com a introdução da função inject(), o Angular permite a injeção funcional em construtores, funções utilitárias ou inicializadores de propriedades, eliminando o acoplamento de parâmetros repetitivos no constructor de classes que herdam de classes base.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Root["Root Injector (providedIn: 'root')<br>Singletons Globais (Auth, HTTP)"] --> Route["Route Injector (Rota /dashboard)<br>Instâncias Escopadas à Rota"]
    Route --> CompParent["Element Injector (DashboardComponent)<br>Serviço de Estado do Dashboard"]
    CompParent --> CompChild["Element Injector (WidgetComponent)<br>Configurações Locais do Widget"]
    style Root fill:#e3f2fd,stroke:#1565c0
    style Route fill:#fff3e0,stroke:#e65100
    style CompParent fill:#e8f5e9,stroke:#2e7d32
    style CompChild fill:#f3e5f5,stroke:#7b1fa2

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Função Funcional inject(): Substituição moderna da injeção via construtor, permitindo composição funcional de lógica. - Modificadores de Resolução: Controle fino da busca de instâncias via @Optional(), @Self(), @SkipSelf() e @Host(). - Tokens de Injeção (InjectionToken): Injeção tipada de valores primitivos, configurações e interfaces abstratas. - Tree-shakable Providers: Serviços declarados com providedIn: 'root' são removidos do bundle final se não forem referenciados.

🛠️ 2. Implementação Prática em Angular Dependency Injection

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// auth.service.ts (DI Funcional e InjectionToken)
import { Injectable, InjectionToken, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

export interface AppApiConfig {
  baseUrl: string;
  timeoutMs: number;
}

export const API_CONFIG = new InjectionToken<AppApiConfig>('API_CONFIG', {
  providedIn: 'root',
  factory: () => ({ baseUrl: 'https://api.empresa.com/v1', timeoutMs: 5000 })
});

@Injectable({ providedIn: 'root' })
export class AuthService {
  // Injeção funcional com a função inject()
  private readonly http = inject(HttpClient);
  private readonly config = inject(API_CONFIG);

  getProfile() {
    return this.http.get(`${this.config.baseUrl}/auth/me`);
  }
}

💡 Análise Passo a Passo do Código

  1. Criação do Token: new InjectionToken<AppApiConfig> cria uma chave tipada e segura para injetar objetos literais.
  2. Uso da Função inject(): inject(HttpClient) obtém a dependência sem necessidade de declarar parâmetros verbosos no construtor.
  3. Escopo Root Garantido: providedIn: 'root' assegura uma única instância singleton compartilhada por toda a aplicação.

🎯 3. Próximos Passos & Sequência Didática

Aula 19 - Formulários Reativos Avançados e Validadores Customizados 📝

Objetivo Pedagógico

Objetivo: Construção de formulários complexos orientados a modelo com FormGroup, FormArray, tipagem estrita e validadores síncronos e assíncronos customizados.

📑 1. Fundamentos Teóricos & Análise Técnica

O módulo Reactive Forms do Angular adota uma abordagem estritamente funcional e orientada a dados para o gerenciamento de formulários. O estado e a validação do formulário são definidos de forma explícita na classe TypeScript através de classes como FormControl, FormGroup e FormArray, enquanto o template apenas se vincula declarativamente aos controles.

A partir do Angular 14+, os formulários reativos são estritamente tipados (Strictly Typed Forms), garantindo que o compilador verifique o tipo dos valores de cada campo em tempo de compilação, prevenindo erros em tempo de execução ao acessar propriedades inexistentes.

A validação de regras de negócio avançadas é realizada através de: 1. Validadores Síncronos: Funções puras que recebem um controle e retornam um mapa de erros (ValidationErrors | null) de forma síncrona. 2. Validadores Assíncronos: Funções que retornam uma Promise ou Observable emitindo o resultado após consultar um backend (ex: verificação de duplicidade de e-mail ou validação de CPF/CNPJ em serviço remoto). 3. FormArray Dinâmico: Permite adição e remoção programática de campos de entrada em tempo de execução (ex: lista dinâmica de telefones ou itens de fatura).

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph LR
    Model["FormGroup Tipado (TypeScript)"] --> Validators["Validadores (Sync / Async)"]
    Model <--> Template["Template HTML ([formGroup])"]
    Validators --> ValidationState["Estado (valid, invalid, dirty, touched)"]
    ValidationState --> UI["Feedback Visual de Validação"]
    style Model fill:#e3f2fd,stroke:#1565c0
    style Validators fill:#fff3e0,stroke:#e65100
    style UI fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Formulários Estritamente Tipados: Garantia de tipos em tempo de compilação para form.value e métodos como patchValue. - Validadores Assíncronos Não-Bloqueantes: Consultas assíncronas que mantêm o status PENDING enquanto aguardam resposta de APIs. - Manipulação Dinâmica com FormArray: Coleções reativas de controles de formulário que crescem conforme a demanda do usuário. - Imutabilidade e Observabilidade: Acesso aos streams reativos de mudanças via valueChanges e statusChanges.

🛠️ 2. Implementação Prática em Angular Reactive Forms

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// user-form.component.ts (FormGroup Tipado com Validador Customizado)
import { Component, inject } from '@angular/core';
import { FormBuilder, Validators, ReactiveFormsModule, AbstractControl, ValidationErrors } from '@angular/forms';
import { CommonModule } from '@angular/common';

// Validador Customizado: Exige e-mail corporativo específico
export function corporateEmailValidator(control: AbstractControl): ValidationErrors | null {
  const value = control.value as string;
  if (!value) return null;
  return value.endsWith('@empresa.com') ? null : { nonCorporateEmail: true };
}

@Component({
  selector: 'app-user-form',
  standalone: true,
  imports: [CommonModule, ReactiveFormsModule],
  template: `
    <form [formGroup]="userForm" (ngSubmit)="onSubmit()">
      <input formControlName="name" placeholder="Nome Completo">
      <input formControlName="email" placeholder="E-mail Corporativo">
      <span *ngIf="userForm.controls.email.errors?.['nonCorporateEmail']" class="error">
        Deve ser um e-mail @empresa.com!
      </span>
      <button type="submit" [disabled]="userForm.invalid">Cadastrar</button>
    </form>
  `
})
export class UserFormComponent {
  private readonly fb = inject(FormBuilder);

  readonly userForm = this.fb.group({
    name: ['', [Validators.required, Validators.minLength(3)]],
    email: ['', [Validators.required, Validators.email, corporateEmailValidator]]
  });

  onSubmit(): void {
    if (this.userForm.valid) {
      console.log('Dados submetidos com sucesso:', this.userForm.value);
    }
  }
}

💡 Análise Passo a Passo do Código

  1. Validador Customizado: corporateEmailValidator inspeciona o valor e retorna um objeto de erro caso o domínio não seja aceito.
  2. FormGroup Tipado: fb.group() infere os tipos dos campos como strings não-nulas de acordo com os valores iniciais.
  3. Feedback Declarativo: O template avalia userForm.controls.email.errors?.['nonCorporateEmail'] para exibir a mensagem corretiva.

🎯 3. Próximos Passos & Sequência Didática

Aula 20 - Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🏆

Objetivo Pedagógico

Objetivo: Construção de uma aplicação corporativa robusta com Standalone Components, roteamento preguiçoso (Lazy Loading), Signals para estado e formulários tipados.

📑 1. Fundamentos Teóricos & Análise Técnica

O Projeto Capstone de Especialização em Angular desafia o desenvolvedor a implementar uma solução de padrão corporativo aplicando a totalidade dos padrões modernos introduzidos nas versões recentes do framework.

O projeto consiste em um Painel de Gestão Operacional de Serviços, estruturado com: 1. Arquitetura 100% Standalone: Inexistência de arquivos NgModule, com inicialização moderna via bootstrapApplication. 2. Carregamento Tardio de Rotas (Lazy Loading): Rotas desacopladas utilizando a sintaxe loadComponent: () => import(...), reduzindo o bundle inicial para menos de 150KB. 3. Gerenciamento de Estado com Signals: Criação de um SignalStore desacoplado para coordenar o estado de listagem, paginação, filtros e persistência local. 4. Guarda de Rotas Funcional (canActivateFn): Proteção de rotas administrativas através de funções puras baseadas em injeção de dependência funcional.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    MainApp["bootstrapApplication(AppComponent)"] --> Router["Roteamento Lazy Loaded"]
    Router -->|loadComponent| Dash["Dashboard Standalone (Signals)"]
    Router -->|loadComponent| Admin["Admin Guarded (canActivateFn)"]
    Dash --> Store["SignalStore (Estado Central)"]
    Dash --> API["Serviço HTTP Tipado"]
    Admin --> Form["Formulários Reativos Tipados"]
    style MainApp fill:#e3f2fd,stroke:#1565c0
    style Router fill:#fff3e0,stroke:#e65100
    style Store fill:#e8f5e9,stroke:#2e7d32
    style Form fill:#f3e5f5,stroke:#7b1fa2

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Modularidade por Domínio: Organização em pastas de features independentes preparadas para arquitetura de monorepo. - Performance de Carregamento: Divisão estratégica do código em chunks carregados sob demanda pelo navegador. - Tipagem de Ponta a Ponta: Interfaces TypeScript compartilhadas entre serviços, formulários e componentes visuais. - Resiliência Operacional: Interceptador HTTP global para captura de erros 401/403 e renovação de tokens.

🛠️ 2. Implementação Prática em Angular 17+ Enterprise Architecture

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// app.routes.ts (Roteamento Moderno com Lazy Loading e Guard Funcional)
import { Routes } from '@angular/router';
import { inject } from '@angular/core';
import { AuthService } from './core/auth.service';

export const routes: Routes = [
  {
    path: '',
    redirectTo: 'dashboard',
    pathMatch: 'full'
  },
  {
    path: 'dashboard',
    loadComponent: () => import('./features/dashboard/dashboard.component').then(m => m.DashboardComponent)
  },
  {
    path: 'gestao',
    canActivate: [() => inject(AuthService).isAdmin()], // Guard Funcional!
    loadComponent: () => import('./features/admin/admin.component').then(m => m.AdminComponent)
  }
];

💡 Análise Passo a Passo do Código

  1. Lazy Loading de Componentes: loadComponent carrega o arquivo JavaScript apenas no momento em que o usuário navega para a rota.
  2. Guard Funcional: () => inject(AuthService).isAdmin() elimina a necessidade de criar classes de guard verbosas.
  3. Alta Escalabilidade: Permite que dezenas de desenvolvedores adicionem novas rotas isoladas sem conflitos no módulo central.

🎯 3. Próximos Passos & Sequência Didática

Exercícios

🏋️ Exercícios do Curso

Lista completa das 20 unidades de exercicios organizadas em 5 módulos didáticos.

Exercícios: Aula 01 📝

Pratique os conceitos básicos de Angular e preparação de ambiente.

Básico

  1. Conceito de SPA: Explique com suas palavras a principal diferença entre uma aplicação SPA e uma aplicação web tradicional (Multi-Page).
  2. Angular CLI: Qual é o comando utilizado para verificar a versão instalada do Angular CLI e do Node.js?

Intermediário

  1. Novo Projeto: Descreva os passos necessários para criar um novo projeto chamado academia-angular, desabilitando os testes iniciais (dica: procure por --skip-tests).
  2. Estrutura de Pastas: Para que serve o arquivo angular.json e por que ele é importante para o desenvolvedor?

Desafio

5. Execução e Alteração: Crie um projeto, execute-o usando ng serve e altere o conteúdo do título no componente raiz. Adicione também um novo parágrafo <p> com seu nome e o nome da sua cidade no arquivo app.component.html.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito de SPA **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Angular e Ecossistema ️**, o conceito abordado (Conceito de SPA) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Angular CLI **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Angular CLI
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Introdução ao Angular e Ecossistema ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Novo Projeto **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Novo Projeto
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Introdução ao Angular e Ecossistema ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Estrutura de Pastas **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Angular e Ecossistema ️**, o conceito abordado (Estrutura de Pastas) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Execução e Alteração **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Execução e Alteração
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Introdução ao Angular e Ecossistema ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 02 📝

Pratique a organização de arquivos e a criação de componentes.

Básico

  1. Componentes: Quais são os quatro arquivos gerados automaticamente pelo comando ng generate component nome-do-componente?
  2. Seletores: Para que serve a propriedade selector nos metadados de um componente?

Intermediário

  1. Registro de Módulo: Na abordagem clássica, em qual array do NgModule o CLI adiciona o novo componente automaticamente?
  2. CLI: Como você criaria um componente dentro de uma subpasta chamada components, usando apenas um comando do CLI? (Exemplo: criar login dentro de src/app/components/login).

Desafio

5. Layout Aninhado: Crie um componente chamado Pai e outro chamado Filho. Tente exibir o componente Filho dentro do template do componente Pai. Depois, exiba o componente Pai no App.component. Descreva o resultado visual.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Componentes **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Componentes
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estrutura do Projeto e Componentes (Abordagem Clássica) ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Seletores **Resposta Comentada:** - **Fundamentação:** No contexto de **Estrutura do Projeto e Componentes (Abordagem Clássica) ️**, o conceito abordado (Seletores) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Registro de Módulo **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Registro de Módulo
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estrutura do Projeto e Componentes (Abordagem Clássica) ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: CLI **Resolução e Implementação:** 
// Estrutura de implementação recomendada para CLI
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estrutura do Projeto e Componentes (Abordagem Clássica) ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Layout Aninhado **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Layout Aninhado
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estrutura do Projeto e Componentes (Abordagem Clássica) ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 03 📝

Pratique a comunicação entre lógica e visual.

Básico

  1. Interpolação: Crie uma variável titulo no seu componente e exiba-a no HTML usando a sintaxe correta.
  2. Property Binding: Como você alteria dinamicamente a cor de fundo de uma div usando Property Binding com a propriedade style.background-color?

Intermediário

  1. Event Binding: Crie uma função que exiba no console do navegador o que o usuário está digitando em um campo <input>. (Dica: use o evento (input) ou (keyup)).
  2. Two-way Binding: Explique por que o [(ngModel)] é chamado de "Banana in a Box". Qual módulo deve ser importado para que ele funcione?

Desafio

5. Calculadora Simples: Crie dois campos de input (numéricos) e exiba a soma desses dois valores em tempo real na tela, conforme o usuário digita. Use Two-way binding.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Interpolação **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Interpolação
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Data Binding**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Property Binding **Resposta Comentada:** - **Fundamentação:** No contexto de **Data Binding**, o conceito abordado (Property Binding) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Event Binding **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Event Binding
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Data Binding**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Two-way Binding **Resposta Comentada:** - **Fundamentação:** No contexto de **Data Binding**, o conceito abordado (Two-way Binding) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Calculadora Simples **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Calculadora Simples
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Data Binding**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 04 📝

Pratique a manipulação do DOM com diretivas.

Básico

  1. ngIf: Crie um botão "Exibir Detalhes". Ao clicar, um parágrafo de texto deve aparecer ou desaparecer da tela usando *ngIf.
  2. ngFor: Crie um array de strings chamado habilidades. Use o *ngFor para listar essas habilidades em uma lista não ordenada (<ul>).

Intermediário

  1. ngClass: Crie uma variável importante (boolean). Use a diretiva ngClass para aplicar a classe CSS .texto-vermelho a um elemento apenas quando importante for verdadeiro.
  2. ngStyle: Crie um controle de "Tamanho do Texto" (um input range). Use ngStyle para que o tamanho da fonte de um parágrafo mude conforme o valor do input.

Desafio

5. Filtro Simples: Crie uma lista de números de 1 a 10. Use o *ngFor para exibir os números, mas adicione um *ngIf interno (em um container ou elemento) para que apenas os números pares sejam mostrados na lista final.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: ngIf **Resolução e Implementação:** 
// Estrutura de implementação recomendada para ngIf
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Diretivas Estruturais e de Atributo ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: ngFor **Resolução e Implementação:** 
// Estrutura de implementação recomendada para ngFor
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Diretivas Estruturais e de Atributo ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: ngClass **Resolução e Implementação:** 
// Estrutura de implementação recomendada para ngClass
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Diretivas Estruturais e de Atributo ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: ngStyle **Resolução e Implementação:** 
// Estrutura de implementação recomendada para ngStyle
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Diretivas Estruturais e de Atributo ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Filtro Simples **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Filtro Simples
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Diretivas Estruturais e de Atributo ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 05 📝

Pratique a troca de dados entre componentes.

Básico

  1. Input: No componente Usuario, receba uma variável nome via @Input(). Exiba esse nome no template HTML.
  2. Output: Crie um evento @Output() chamado aoCurtir em um componente de Foto. O evento deve disparar toda vez que o usuário clicar em um ícone de coração.

Intermediário

  1. Objeto Inteiro: É possível passar um objeto inteiro (como um Produto com nome, preco e img) via @Input()? Como seria a sintaxe no componente pai para passar esse objeto?
  2. EventEmitter: Qual a finalidade do comando this.meuEvento.emit(valor) dentro de uma função do componente filho?

Desafio

5. Carrinho de Compras: Crie um componente ProdutoItem. O pai deve passar as informações do produto via @Input. O filho deve ter um botão "Adicionar ao Carrinho". Ao clicar, o pai deve receber a notificação, receber o ID do produto e aumentar um contador de itens no carrinho que fica no topo da página.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Input **Resposta Comentada:** - **Fundamentação:** No contexto de **Comunicação entre Componentes**, o conceito abordado (Input) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Output **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Output
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Comunicação entre Componentes**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Objeto Inteiro **Resposta Comentada:** - **Fundamentação:** No contexto de **Comunicação entre Componentes**, o conceito abordado (Objeto Inteiro) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: EventEmitter **Resolução e Implementação:** 
// Estrutura de implementação recomendada para EventEmitter
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Comunicação entre Componentes**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Carrinho de Compras **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Carrinho de Compras
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Comunicação entre Componentes**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 06 📝

Pratique a criação de serviços e o compartilhamento de dados.

Básico

  1. Geração: Qual o comando CLI completo para gerar um serviço chamado Config dentro da pasta core/services?
  2. ProvidedIn: O que significa o parâmetro { providedIn: 'root' } dentro do decorator @Injectable?

Intermediário

  1. Injeção: Como você injeta um serviço chamado LogService dentro do construtor de um componente? Escreva a linha de código.
  2. Singleton: Se dois componentes diferentes injetarem o mesmo serviço e um deles alterar uma variável dentro desse serviço, o outro componente verá a mudança? Justifique.

Desafio

5. Simulação de API: Crie um serviço chamado PostService. Ele deve ter um método que retorne um array de objetos (com titulo e autor). Injete esse serviço em um componente e use o *ngFor para exibir esses posts formatados como cards no HTML.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Geração **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Geração
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Serviços e Injeção de Dependência**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: ProvidedIn **Resposta Comentada:** - **Fundamentação:** No contexto de **Serviços e Injeção de Dependência**, o conceito abordado (ProvidedIn) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Injeção **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Injeção
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Serviços e Injeção de Dependência**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Singleton **Resposta Comentada:** - **Fundamentação:** No contexto de **Serviços e Injeção de Dependência**, o conceito abordado (Singleton) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Simulação de API **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Simulação de API
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Serviços e Injeção de Dependência**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 07 📝

Pratique a navegação em SPAs.

Básico

  1. Tag Principal: Qual é a tag HTML que deve ser colocada no template para que as rotas sejam renderizadas?
  2. Link Interno: Qual diretiva substitui o atributo href do HTML tradicional para evitar o refresh da página?

Intermediário

  1. Parâmetros: Como você define uma rota que aceita um parâmetro chamado username no array de rotas?
  2. Redirect: Como configurar uma rota para que, quando o usuário digitar uma URL inexistente, ele seja redirecionado para a /home?

Desafio

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Tag Principal **Resposta Comentada:** - **Fundamentação:** No contexto de **Roteamento (Abordagem Clássica) ️**, o conceito abordado (Tag Principal) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Link Interno **Resposta Comentada:** - **Fundamentação:** No contexto de **Roteamento (Abordagem Clássica) ️**, o conceito abordado (Link Interno) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Parâmetros **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Parâmetros
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Roteamento (Abordagem Clássica) ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Redirect **Resposta Comentada:** - **Fundamentação:** No contexto de **Roteamento (Abordagem Clássica) ️**, o conceito abordado (Redirect) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Navegação via Código **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Navegação via Código
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Roteamento (Abordagem Clássica) ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 08 📝

Pratique a transição para o Angular Moderno.

Básico

  1. Flag Standalone: Qual propriedade deve ser adicionada ao decorator @Component para torná-lo um componente independente?
  2. Imports: Onde são importadas as dependências (como CommonModule ou outros componentes) na abordagem Standalone?

Intermediário

  1. Bootstrap: Qual função substitui o platformBrowserDynamic().bootstrapModule() no arquivo main.ts de uma aplicação puramente standalone?
  2. CLI: Escreva o comando do CLI para gerar um componente chamado VideoPlayer que seja standalone desde a sua criação.

Desafio

5. Migração: Imagine que você tem um componente clássico registrado no AppModule. Liste os 3 passos principais que você faria para transformá-lo em um componente Standalone pronto para ser usado sem módulos.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Flag Standalone **Resposta Comentada:** - **Fundamentação:** No contexto de **Standalone Components**, o conceito abordado (Flag Standalone) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Imports **Resposta Comentada:** - **Fundamentação:** No contexto de **Standalone Components**, o conceito abordado (Imports) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Bootstrap **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Bootstrap
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Standalone Components**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: CLI **Resolução e Implementação:** 
// Estrutura de implementação recomendada para CLI
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Standalone Components**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Migração **Resposta Comentada:** - **Fundamentação:** No contexto de **Standalone Components**, o conceito abordado (Migração) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios: Aula 09 📝

Pratique a navegação no Angular Moderno.

Básico

  1. Provedor de Rota: Qual função substitui o RouterModule.forRoot() para configurar rotas em uma aplicação standalone?
  2. Importação no Componente: Se eu quero usar o router-outlet em um componente standalone, o que devo adicionar ao seu decorator @Component?

Intermediário

  1. loadComponent: Qual a principal diferença entre a propriedade component e a propriedade loadComponent na definição de uma rota?
  2. Configuração de App: No arquivo main.ts, onde passamos a configuração do roteador para a função bootstrapApplication?

Desafio

  1. Refatoração de Lazy Loading: Transforme a rota abaixo, que usa módulos, para o formato standalone usando componente: 
    // Formato antigo (Módulo)
{ path: 'admin', loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule) }
    Escreva como ficaria a nova versão.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Provedor de Rota **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Provedor de Rota
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Roteamento no Modelo Standalone ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Importação no Componente **Resposta Comentada:** - **Fundamentação:** No contexto de **Roteamento no Modelo Standalone ️**, o conceito abordado (Importação no Componente) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: loadComponent **Resposta Comentada:** - **Fundamentação:** No contexto de **Roteamento no Modelo Standalone ️**, o conceito abordado (loadComponent) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Configuração de App **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Configuração de App
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Roteamento no Modelo Standalone ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Refatoração de Lazy Loading **Resposta Comentada:** - **Fundamentação:** No contexto de **Roteamento no Modelo Standalone ️**, o conceito abordado (Refatoração de Lazy Loading) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios: Aula 10 📝

Pratique a criação de formulários e validações.

Básico

  1. Abordagens: Quais são as duas principais formas de criar formulários no Angular?
  2. ngModel: Em qual das abordagens o ngModel é a peça central para capturar os dados?

Intermediário

  1. Validators: Cite 3 validadores nativos do Angular (ex: Validators.required) e explique o que cada um faz.
  2. FormGroup: No Reactive Forms, para que serve o FormGroup e como ele se relaciona com o FormControl?

Desafio

5. Formulário Reativo: Crie um pequeno código TypeScript de um FormGroup que tenha dois campos: idade (mínimo 18) e termoAceite (deve ser verdadeiro). Como você configuraria esses validadores?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Abordagens **Resposta Comentada:** - **Fundamentação:** No contexto de **Formulários no Angular**, o conceito abordado (Abordagens) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: ngModel **Resposta Comentada:** - **Fundamentação:** No contexto de **Formulários no Angular**, o conceito abordado (ngModel) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Validators **Resposta Comentada:** - **Fundamentação:** No contexto de **Formulários no Angular**, o conceito abordado (Validators) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: FormGroup **Resposta Comentada:** - **Fundamentação:** No contexto de **Formulários no Angular**, o conceito abordado (FormGroup) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Formulário Reativo **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Formulário Reativo
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Formulários no Angular**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 11 📝

Pratique a integração com serviços externos.

Básico

  1. Configuração: Qual utilitário devemos adicionar ao array de providers no bootstrap da aplicação para liberar o uso de requisições HTTP?
  2. Verbos HTTP: Quais são os 4 verbos HTTP mais comuns usados em APIs REST para CRUD (Create, Read, Update, Delete)?

Intermediário

  1. Tipagem: Como você definiria a tipagem do retorno de um http.get para que ele retorne um array de uma interface chamada IUsuario?
  2. Assincronismo: O que acontece se você esquecer de chamar o método .subscribe() após uma requisição http.get() no seu componente?

Desafio

5. Tratamento de Erros: Pesquise como o método .subscribe() pode receber um objeto com next e error. Escreva um exemplo de código que trate o erro caso a API de busca de CEP retorne um erro 404.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Configuração **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Configuração
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **HTTP Client e Consumo de API REST**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Verbos HTTP **Resposta Comentada:** - **Fundamentação:** No contexto de **HTTP Client e Consumo de API REST**, o conceito abordado (Verbos HTTP) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Tipagem **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Tipagem
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **HTTP Client e Consumo de API REST**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Assincronismo **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Assincronismo
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **HTTP Client e Consumo de API REST**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Tratamento de Erros **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Tratamento de Erros
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **HTTP Client e Consumo de API REST**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 12 📝

Pratique a manipulação de fluxos de dados com RxJS.

Básico

  1. Conceito: Qual a principal diferença entre um Observable e uma Promise?
  2. Async Pipe: Qual o benefício de usar o pipe | async no HTML em vez de fazer o .subscribe() manualmente no TypeScript?

Intermediário

  1. map vs filter: Explique a diferença de comportamento entre o operador map e o operador filter.
  2. BehaviorSubject: Por que o BehaviorSubject é geralmente preferido em relação ao Subject comum para armazenar o estado atual de um usuário logado?

Desafio

5. Encadeamento: Escreva um exemplo de código usando .pipe() que receba uma lista de números, multiplique cada um por 2 (use map) e depois retorne apenas os números que forem maiores que 10 (use filter).

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **RxJS e Programação Reativa ⚡**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Async Pipe **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Async Pipe
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **RxJS e Programação Reativa ⚡**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: map vs filter **Resposta Comentada:** - **Fundamentação:** No contexto de **RxJS e Programação Reativa ⚡**, o conceito abordado (map vs filter) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: BehaviorSubject **Resposta Comentada:** - **Fundamentação:** No contexto de **RxJS e Programação Reativa ⚡**, o conceito abordado (BehaviorSubject) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Encadeamento **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Encadeamento
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **RxJS e Programação Reativa ⚡**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 13 📝

Pratique a organização de projetos escaláveis.

Básico

  1. LIFT: O que significa o acrônimo LIFT nas recomendações de estilo do Angular?
  2. Pasta Core: Que tipo de arquivos costumamos colocar dentro da pasta core/? Cite 2 exemplos.

Intermediário

  1. Shared vs Core: Qual a principal diferença entre a pasta shared/ e a pasta core/ em termos de instância e uso?
  2. Barrel Files: Explique para que serve um arquivo index.ts dentro de uma pasta de componentes.

Desafio

5. Proposição de Estrutura: Imagine que você vai criar um módulo de "Gestão de Estoque". Quais pastas e arquivos você criaria para seguir a arquitetura de "Features" ensinada na aula? Descreva a hierarquia.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: LIFT **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura e Organização Profissional ️**, o conceito abordado (LIFT) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Pasta Core **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura e Organização Profissional ️**, o conceito abordado (Pasta Core) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Shared vs Core **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura e Organização Profissional ️**, o conceito abordado (Shared vs Core) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Barrel Files **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura e Organização Profissional ️**, o conceito abordado (Barrel Files) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Proposição de Estrutura **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Proposição de Estrutura
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Arquitetura e Organização Profissional ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 14 📝

Pratique a criação de interfaces modernas.

Básico

  1. Isolamento: Explique o que é o "Encapsulamento de Estilo" do Angular e qual a sua principal vantagem.
  2. Angular Material: Qual o comando do CLI para instalar o Angular Material em um projeto existente?

Intermediário

  1. Variáveis CSS: Como você definiria uma variável CSS chamada --main-bg e a utilizaria em um seletor .container?
  2. Tailwind: Qual a principal diferença filosófica entre usar Angular Material e usar Tailwind CSS?

Desafio

5. Tematização: Escreva um pequeno trecho de código CSS que mude a cor de fundo de um botão quando a classe .dark-theme estiver presente em um elemento pai (como o body).

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Isolamento **Resposta Comentada:** - **Fundamentação:** No contexto de **Estilização Moderna e Componentes de UI**, o conceito abordado (Isolamento) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Angular Material **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Angular Material
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estilização Moderna e Componentes de UI**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Variáveis CSS **Resposta Comentada:** - **Fundamentação:** No contexto de **Estilização Moderna e Componentes de UI**, o conceito abordado (Variáveis CSS) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Tailwind **Resposta Comentada:** - **Fundamentação:** No contexto de **Estilização Moderna e Componentes de UI**, o conceito abordado (Tailwind) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Tematização **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Tematização
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estilização Moderna e Componentes de UI**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios: Aula 15 📝

Pratique a entrega final da sua aplicação.

Básico

  1. Build: Qual o comando do CLI para gerar os arquivos finais de produção de um projeto Angular?
  2. Destino: Para qual pasta (por padrão) o Angular envia os arquivos gerados após o comando de build?

Intermediário

  1. base-href: Para que serve a flag --base-href durante o processo de build para deploy no GitHub Pages?
  2. Otimização: O que o processo de "Minificação" e "Uglification" (ofuscação) faz com o seu código JavaScript final?

Desafio

5. Análise de Performance: Abra o site que você criou, pressione F12 (DevTools), vá na aba "Lighthouse" e gere um relatório de Desktop. Liste 2 sugestões de melhoria que o relatório deu para o seu projeto.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Build **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Build
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Build, Deploy e Performance**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Destino **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Destino
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Build, Deploy e Performance**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: base-href **Resposta Comentada:** - **Fundamentação:** No contexto de **Build, Deploy e Performance**, o conceito abordado (base-href) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Otimização **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Otimização
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Build, Deploy e Performance**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Análise de Performance **Resposta Comentada:** - **Fundamentação:** No contexto de **Build, Deploy e Performance**, o conceito abordado (Análise de Performance) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Projeto Final: Checklist de Entrega 📑

Use este checklist para garantir que seu projeto final atenda a todos os requisitos do curso.

Estrutura

  • O projeto utiliza apenas Standalone Components?
  • O projeto segue a organização de pastas Core, Shared e Features?
  • O arquivo app.module.ts foi removido e o bootstrap ocorre via main.ts?

Funcionalidades

  • Existe navegação entre pelo menos 3 rotas diferentes?
  • Há consumo de uma API externa (ou JSONPlaceholder) via HttpClient?
  • Foi implementado um formulário do tipo Reativo com validações?
  • Existe uma busca em tempo real usando operadores RxJS?

Design e UX

  • A interface utiliza Angular Material ou Tailwind CSS?
  • O site é responsivo (funciona bem em celular e desktop)?
  • Existe feedback visual para o usuário (loading spinners ou mensagens de erro)?

Finalização

  • O projeto foi publicado no GitHub Pages?
  • O README contém instruções de instalação e uso?
  • Todas as dependências inúteis foram removidas do package.json?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Nível Bronze: Fixação Conceitual - **Resolução:** O domínio de **Projeto Final Integrador** exige a compreensão de sua arquitetura base, fluxo de dados e separação de responsabilidades no projeto. ### Nível Prata: Aplicação Prática - **Resolução:** A implementação prática deve adotar boas práticas de mercado, convenções da linguagem (typescript) e testes de integridade para validar entradas e saídas. ### Nível Ouro: Desafio e Cenário Real - **Resolução:** Em cenários de alta demanda, a estratégia consiste em isolar gargalos via profiling/logs estruturados, aplicar mitigação com fallback seguro e atualizar a documentação operacional.

Projetos

🚀 Projetos do Curso

Lista completa das 20 unidades de projetos organizadas em 5 módulos didáticos.

Projeto 01: Meu Primeiro App Angular 🚀

Objetivo

Criar uma aplicação Angular básica e realizar as primeiras alterações visuais.

Requisitos

  • Instalar o Angular CLI.
  • Criar um projeto chamado aula-01-projeto.
  • Alterar o título no arquivo app.component.html.
  • Adicionar um parágrafo com uma breve descrição sobre você.
  • Executar o projeto no navegador usando ng serve.

Desafio Extra

Tente mudar a cor do parágrafo que você criou usando CSS no arquivo app.component.css.

Projeto 02: Layout com Componentes 🏗️

Objetivo

Praticar a criação e organização de componentes para formar um layout de Dashboard.

Requisitos

  • Criar quatro componentes: Header, Sidebar, Content e Footer.
  • Organizar o app.component.html para que o Header fique no topo, a Sidebar na esquerda e o Content no centro.
  • Adicionar cores de fundo diferentes para cada componente para identificá-los.

Desafio Extra

Crie um componente chamado Card e tente repetir ele 3 vezes dentro do componente Content.

Projeto 03: Calculadora de IMC ⚖️

Objetivo

Utilizar Data Binding para criar uma calculadora de Índice de Massa Corporal funcional.

Requisitos

  • Criar dois inputs (Peso e Altura) usando [(ngModel)].
  • Criar um botão "Calcular" que dispara uma função (click).
  • Exibir o resultado do cálculo na tela usando Interpolação {{ }}.
  • Limpar os campos após o cálculo.

Desafio Extra

Mude a cor do resultado (ex: Vermelho para IMC alto, Verde para normal) usando Property Binding no atributo style.

Projeto 04: Lista de Tarefas (Todo) v1 ✅

Objetivo

Aplicar diretivas estruturais para gerenciar uma lista de itens.

Requisitos

  • Criar um array de tarefas no TypeScript.
  • Usar *ngFor para listar as tarefas na tela.
  • Usar *ngIf para exibir uma mensagem "Nenhuma tarefa pendente" se a lista estiver vazia.
  • Criar um input para adicionar novas tarefas à lista.

Desafio Extra

Adicione um botão ao lado de cada tarefa que permita removê-la da lista.

Projeto 05: Galeria de Produtos 🛒

Objetivo

Praticar a comunicação entre componentes usando @Input e @Output.

Requisitos

  • Criar um componente pai Catalog e um componente filho ProductCard.
  • O pai deve enviar as informações do produto via @Input para o filho.
  • O filho deve ter um botão "Comprar" que emite um evento via @Output.
  • O pai deve exibir um alerta com o nome do produto sempre que o botão for clicado no filho.

Desafio Extra

Crie uma variável "Carrinho" no componente pai que conte quantos produtos foram clicados.

Projeto 06: Controle de Estoque com Serviços 📦

Objetivo

Centralizar a lógica de dados em um serviço para compartilhamento entre componentes.

Requisitos

  • Criar um EstoqueService com uma lista privada de produtos.
  • Implementar métodos adicionar() e listar() no serviço.
  • Criar dois componentes: um formulário para adicionar e uma lista para exibir.
  • Ambos os componentes devem injetar e usar o mesmo serviço.

Desafio Extra

Implemente um método no serviço para remover um item pelo ID e use-o no componente de lista.

Projeto 07: Site Institucional 🗺️

Objetivo

Configurar o roteamento clássico (NgModule) para criar uma navegação entre páginas.

Requisitos

  • Criar três componentes representando as páginas: Home, Sobre e Contato.
  • Configurar o arquivo app-routing.module.ts.
  • Usar <router-outlet> no layout principal.
  • Criar uma barra de navegação com routerLink.

Desafio Extra

Adicione uma rota curinga (**) para lidar com páginas não encontradas, exibindo um componente de erro 404.

Projeto 08: Perfil do Usuário Standalone 📦

Objetivo

Migrar a aplicação para o modelo moderno de Standalone Components.

Requisitos

  • Criar um componente Perfil com a flag --standalone.
  • Importar o CommonModule diretamente no componente.
  • Rodar a aplicação usando bootstrapApplication(AppComponent) no main.ts.
  • Remover o arquivo app.module.ts se possível.

Desafio Extra

Importe um componente standalone dentro de outro componente standalone e use-o no template.

Projeto 09: App de Notícias com Roteamento Moderno 🗺️

Objetivo

Configurar o roteamento em uma aplicação puramente standalone.

Requisitos

  • Usar a função provideRouter() no main.ts.
  • Criar rotas para Noticias e Esportes.
  • Implementar Lazy Loading usando loadComponent.
  • Importar RouterOutlet e RouterLink nos componentes standalone necessários.

Desafio Extra

Passe um parâmetro de ID na URL da notícia e exiba-o na tela do componente de detalhe.

Projeto 10: Formulário de Contato Reativo 📝

Objetivo

Desenvolver um formulário robusto com validações em tempo real usando Reactive Forms.

Requisitos

  • Criar um FormGroup com os campos: Nome, E-mail e Assunto.
  • Adicionar validadores: required para todos e email para o campo de e-mail.
  • Exibir mensagens de erro apenas quando o campo for "touched" e estiver "invalid".
  • Desabilitar o botão de envio até que o formulário seja válido.

Desafio Extra

Crie um validador personalizado que impeça o uso de e-mails de domínios específicos (ex: teste.com).

Projeto 11: Buscador de CEP (ViaCEP) 🌐

Objetivo

Conectar a aplicação ao mundo real consumindo uma API REST externa.

Requisitos

  • Habilitar o provideHttpClient() no bootstrap.
  • Criar um serviço para realizar a chamada ao https://viacep.com.br/ws/.
  • Injetar o serviço no componente e processar o retorno no .subscribe().
  • Exibir o Logradouro, Bairro e Cidade na tela.

Desafio Extra

Trate o erro caso o CEP digitado não exista ou tenha formato inválido, exibindo uma mensagem amigável.

Projeto 12: Barra de Busca Inteligente com RxJS ⚡

Objetivo

Usar operadores de fluxo de dados para otimizar pesquisas em tempo real.

Requisitos

  • Criar um campo de busca que emite eventos a cada tecla digitada.
  • Usar debounceTime(300) para não disparar requisições a cada letra.
  • Usar switchMap para cancelar buscas anteriores se a atual mudar.
  • Exibir os resultados usando o Async Pipe no HTML.

Desafio Extra

Use o operador distinctUntilChanged para evitar buscas idênticas consecutivas.

Projeto 13: Refactoring para Arquitetura Profissional 🏗️

Objetivo

Reorganizar a estrutura de pastas do projeto seguindo padrões de mercado.

Requisitos

  • Criar as pastas core/, shared/ e features/.
  • Mover componentes de layout (NavBar, Footer) para a pasta correta.
  • Mover serviços de autenticação ou globais para core/.
  • Implementar Barrel Files (index.ts) para exportar múltiplos componentes de uma pasta.

Desafio Extra

Crie uma pasta models/ dentro de shared/ e defina interfaces TypeScript para as principais entidades do seu projeto.

Projeto 14: Dashboard com Angular Material 🎨

Objetivo

Aplicar bibliotecas de componentes profissionais para elevar o nível visual da app.

Requisitos

  • Instalar o Angular Material usando ng add.
  • Usar o componente MatToolbar e MatButton no cabeçalho.
  • Criar uma listagem de dados usando MatTable ou MatCard.
  • Implementar um botão de "Excluir" que abre um MatDialog de confirmação.

Desafio Extra

Configure um tema personalizado alterando as cores primária e acento no arquivo de estilos globais.

Projeto 15: Deploy Real no GitHub Pages 🚀

Objetivo

Realizar o build oficial e publicar o projeto integrado na internet.

Requisitos

  • Configurar os arquivos de environment (dev/prod).
  • Executar o comando ng build --base-href /seu-repositorio/.
  • Utilizar a ferramenta angular-cli-ghpages para fazer o upload.
  • Verificar o site rodando na URL pública do GitHub.

Desafio Extra

Rode um teste de Lighthouse no Chrome DevTools e tente atingir uma pontuação acima de 90 em Performance e Acessibilidade.

Projeto 16: Projeto Final - Gerenciador de Filmes 🏆

Objetivo

Construir uma aplicação completa integrando todos os pilares do curso Angular.

Requisitos

  • Sistema 100% Standalone com Arquitetura Core/Shared/Features.
  • Navegação completa entre Home, Busca de Filmes e Detalhes.
  • Busca reativa (debounce, switchMap) consumindo a API do TMDB.
  • Formulário de avaliação de filmes com validações.
  • Design responsivo e moderno usando Material Design ou Tailwind.
  • Deploy funcional no GitHub Pages.

Desafio Extra

Implemente a funcionalidade de "Favoritos" usando um BehaviorSubject para que o número de filmes favoritos atualize em tempo real no cabeçalho do site.

Quizzes

🧠 Quizzes de Fixação

Lista completa das 20 unidades de quizzes organizadas em 5 módulos didáticos.

🧠 Quiz 01 – Introdução ao Angular e Ecossistema 🅰️

  1. Qual é o conceito fundamental e objetivo principal de Introdução ao Angular e Ecossistema 🅰️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Introdução ao Angular e Ecossistema 🅰️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Introdução ao Angular e Ecossistema 🅰️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Introdução ao Angular e Ecossistema 🅰️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Introdução ao Angular e Ecossistema 🅰️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Introdução ao Angular e Ecossistema 🅰️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Introdução ao Angular e Ecossistema 🅰️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Introdução ao Angular e Ecossistema 🅰️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Introdução ao Angular e Ecossistema 🅰️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Introdução ao Angular e Ecossistema 🅰️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 02 – Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️

  1. Qual é o conceito fundamental e objetivo principal de Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Estrutura do Projeto e Componentes (Abordagem Clássica) 🏗️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 03 – Data Binding 📡

  1. Qual é o conceito fundamental e objetivo principal de Data Binding 📡?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Data Binding 📡?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Data Binding 📡, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Data Binding 📡?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Data Binding 📡 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Data Binding 📡, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Data Binding 📡?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Data Binding 📡 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Data Binding 📡 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Data Binding 📡 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 04 – Diretivas Estruturais e de Atributo 🛠️

  1. Qual é o conceito fundamental e objetivo principal de Diretivas Estruturais e de Atributo 🛠️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Diretivas Estruturais e de Atributo 🛠️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Diretivas Estruturais e de Atributo 🛠️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Diretivas Estruturais e de Atributo 🛠️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Diretivas Estruturais e de Atributo 🛠️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Diretivas Estruturais e de Atributo 🛠️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Diretivas Estruturais e de Atributo 🛠️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Diretivas Estruturais e de Atributo 🛠️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Diretivas Estruturais e de Atributo 🛠️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Diretivas Estruturais e de Atributo 🛠️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 05 – Comunicação entre Componentes 🔄

  1. Qual é o conceito fundamental e objetivo principal de Comunicação entre Componentes 🔄?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Comunicação entre Componentes 🔄?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Comunicação entre Componentes 🔄, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Comunicação entre Componentes 🔄?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Comunicação entre Componentes 🔄 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Comunicação entre Componentes 🔄, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Comunicação entre Componentes 🔄?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Comunicação entre Componentes 🔄 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Comunicação entre Componentes 🔄 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Comunicação entre Componentes 🔄 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 06 – Serviços e Injeção de Dependência 💉

  1. Qual é o conceito fundamental e objetivo principal de Serviços e Injeção de Dependência 💉?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Serviços e Injeção de Dependência 💉?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Serviços e Injeção de Dependência 💉, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Serviços e Injeção de Dependência 💉?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Serviços e Injeção de Dependência 💉 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Serviços e Injeção de Dependência 💉, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Serviços e Injeção de Dependência 💉?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Serviços e Injeção de Dependência 💉 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Serviços e Injeção de Dependência 💉 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Serviços e Injeção de Dependência 💉 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 07 – Roteamento (Abordagem Clássica) 🛣️

  1. Qual é o conceito fundamental e objetivo principal de Roteamento (Abordagem Clássica) 🛣️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Roteamento (Abordagem Clássica) 🛣️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Roteamento (Abordagem Clássica) 🛣️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Roteamento (Abordagem Clássica) 🛣️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Roteamento (Abordagem Clássica) 🛣️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Roteamento (Abordagem Clássica) 🛣️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Roteamento (Abordagem Clássica) 🛣️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Roteamento (Abordagem Clássica) 🛣️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Roteamento (Abordagem Clássica) 🛣️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Roteamento (Abordagem Clássica) 🛣️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 08 – Standalone Components 📦

  1. Qual é o conceito fundamental e objetivo principal de Standalone Components 📦?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Standalone Components 📦?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Standalone Components 📦, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Standalone Components 📦?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Standalone Components 📦 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Standalone Components 📦, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Standalone Components 📦?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Standalone Components 📦 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Standalone Components 📦 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Standalone Components 📦 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 09 – Roteamento no Modelo Standalone 🗺️

  1. Qual é o conceito fundamental e objetivo principal de Roteamento no Modelo Standalone 🗺️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Roteamento no Modelo Standalone 🗺️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Roteamento no Modelo Standalone 🗺️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Roteamento no Modelo Standalone 🗺️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Roteamento no Modelo Standalone 🗺️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Roteamento no Modelo Standalone 🗺️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Roteamento no Modelo Standalone 🗺️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Roteamento no Modelo Standalone 🗺️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Roteamento no Modelo Standalone 🗺️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Roteamento no Modelo Standalone 🗺️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 10 – Formulários no Angular 📝

  1. Qual é o conceito fundamental e objetivo principal de Formulários no Angular 📝?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Formulários no Angular 📝?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Formulários no Angular 📝, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Formulários no Angular 📝?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Formulários no Angular 📝 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Formulários no Angular 📝, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Formulários no Angular 📝?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Formulários no Angular 📝 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Formulários no Angular 📝 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Formulários no Angular 📝 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 11 – HTTP Client e Consumo de API REST 🌐

  1. Qual é o conceito fundamental e objetivo principal de HTTP Client e Consumo de API REST 🌐?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de HTTP Client e Consumo de API REST 🌐?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em HTTP Client e Consumo de API REST 🌐, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em HTTP Client e Consumo de API REST 🌐?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de HTTP Client e Consumo de API REST 🌐 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em HTTP Client e Consumo de API REST 🌐, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em HTTP Client e Consumo de API REST 🌐?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a HTTP Client e Consumo de API REST 🌐 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar HTTP Client e Consumo de API REST 🌐 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a HTTP Client e Consumo de API REST 🌐 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 12 – RxJS e Programação Reativa ⚡

  1. Qual é o conceito fundamental e objetivo principal de RxJS e Programação Reativa ⚡?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de RxJS e Programação Reativa ⚡?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em RxJS e Programação Reativa ⚡, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em RxJS e Programação Reativa ⚡?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de RxJS e Programação Reativa ⚡ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em RxJS e Programação Reativa ⚡, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em RxJS e Programação Reativa ⚡?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a RxJS e Programação Reativa ⚡ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar RxJS e Programação Reativa ⚡ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a RxJS e Programação Reativa ⚡ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 13 – Arquitetura e Organização Profissional 🏗️

  1. Qual é o conceito fundamental e objetivo principal de Arquitetura e Organização Profissional 🏗️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Arquitetura e Organização Profissional 🏗️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Arquitetura e Organização Profissional 🏗️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Arquitetura e Organização Profissional 🏗️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Arquitetura e Organização Profissional 🏗️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Arquitetura e Organização Profissional 🏗️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Arquitetura e Organização Profissional 🏗️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Arquitetura e Organização Profissional 🏗️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Arquitetura e Organização Profissional 🏗️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Arquitetura e Organização Profissional 🏗️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 14 – Estilização Moderna e Componentes de UI 🎨

  1. Qual é o conceito fundamental e objetivo principal de Estilização Moderna e Componentes de UI 🎨?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Estilização Moderna e Componentes de UI 🎨?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Estilização Moderna e Componentes de UI 🎨, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Estilização Moderna e Componentes de UI 🎨?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Estilização Moderna e Componentes de UI 🎨 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Estilização Moderna e Componentes de UI 🎨, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Estilização Moderna e Componentes de UI 🎨?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Estilização Moderna e Componentes de UI 🎨 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Estilização Moderna e Componentes de UI 🎨 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Estilização Moderna e Componentes de UI 🎨 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 15 – Build, Deploy e Performance 🚀

  1. Qual é o conceito fundamental e objetivo principal de Build, Deploy e Performance 🚀?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Build, Deploy e Performance 🚀?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Build, Deploy e Performance 🚀, Deploy e Performance 🚀, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Build, Deploy e Performance 🚀?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Build, Deploy e Performance 🚀 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Build, Deploy e Performance 🚀, Deploy e Performance 🚀, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Build, Deploy e Performance 🚀?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Build, Deploy e Performance 🚀 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Build, Deploy e Performance 🚀 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Build, Deploy e Performance 🚀 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 16 – Projeto Final Integrador 🏆

  1. Qual é o conceito fundamental e objetivo principal de Projeto Final Integrador 🏆?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Projeto Final Integrador 🏆?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Projeto Final Integrador 🏆, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Projeto Final Integrador 🏆?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Projeto Final Integrador 🏆 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Projeto Final Integrador 🏆, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Projeto Final Integrador 🏆?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Projeto Final Integrador 🏆 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Projeto Final Integrador 🏆 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Projeto Final Integrador 🏆 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 17 – Arquitetura com Standalone Components e Signals 🚀

  1. Qual o propósito principal de Arquitetura com Standalone Components e Signals 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Arquitetura com Standalone Components e Signals 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Arquitetura com Standalone Components e Signals 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Arquitetura com Standalone Components e Signals 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Arquitetura com Standalone Components e Signals 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Arquitetura com Standalone Components e Signals 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Arquitetura com Standalone Components e Signals 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Arquitetura com Standalone Components e Signals 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Arquitetura com Standalone Components e Signals 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Arquitetura com Standalone Components e Signals 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 18 – Injeção de Dependências Avançada e Scopes 🚀

  1. Qual o propósito principal de Injeção de Dependências Avançada e Scopes 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Injeção de Dependências Avançada e Scopes 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Injeção de Dependências Avançada e Scopes 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Injeção de Dependências Avançada e Scopes 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Injeção de Dependências Avançada e Scopes 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Injeção de Dependências Avançada e Scopes 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Injeção de Dependências Avançada e Scopes 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Injeção de Dependências Avançada e Scopes 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Injeção de Dependências Avançada e Scopes 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Injeção de Dependências Avançada e Scopes 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 19 – Formulários Reativos Avançados e Validadores Customizados 🚀

  1. Qual o propósito principal de Formulários Reativos Avançados e Validadores Customizados 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Formulários Reativos Avançados e Validadores Customizados 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Formulários Reativos Avançados e Validadores Customizados 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Formulários Reativos Avançados e Validadores Customizados 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Formulários Reativos Avançados e Validadores Customizados 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Formulários Reativos Avançados e Validadores Customizados 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Formulários Reativos Avançados e Validadores Customizados 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Formulários Reativos Avançados e Validadores Customizados 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Formulários Reativos Avançados e Validadores Customizados 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Formulários Reativos Avançados e Validadores Customizados 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 20 – Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀

  1. Qual o propósito principal de Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Projeto Capstone: Aplicação Angular Autônoma de Alta Escala 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

Slides

Configuração

Setup e Ambiente 🛠️

Prepare sua máquina para o desenvolvimento profissional com Angular.

1. Node.js (Motor)

O Angular exige o Node.js em sua versão LTS (Long Term Support).

2. Angular CLI (A Arrumadeira)

Instale a interface de linha de comando oficial globalmente.

$ npm install -g @angular/cli

3. VS Code (O Palácio)

Recomendamos o Visual Studio Code com as seguintes extensões: * Angular Language Service: Inteligência de código para Angular. * ESLint: Para manter o código limpo. * Prettier: Para formatação automática.

4. Extensões Úteis no Chrome

  • Angular DevTools: Essencial para debugar componentes e performance.

Tudo pronto?

Siga para a vAula 01 para criar seu primeiro projeto!

Setup 01: Android Studio 🤖

O Android Studio é a IDE oficial para o desenvolvimento Android.

1. Requisitos de Sistema

  • RAM: Mínimo 8GB (Sugerido 16GB+).
  • Espaço: Mínimo 10GB para IDE + SDKs.
  • Processador: Intel Core i5 ou equivalente.

2. Instalação

  1. Acesse o site oficial: developer.android.com/studio.
  2. Baixe a versão mais recente para o seu Sistema Operacional.
  3. Execute o instalador e escolha a opção "Standard" na configuração inicial.

3. Configurando o SDK

  • Após a instalação, vá em Settings > Languages & Frameworks > Android SDK.
  • Certifique-se de que a versão mais recente do Android (estável) esteja instalada.
  • Na aba SDK Tools, instale o "Android Emulator" e o "Intel x86 Emulator Accelerator (HAXM)" se estiver no Windows com Intel.

4. Criando um Emulador (AVD)

  1. Abra o Device Manager.
  2. Clique em Create Device.
  3. Escolha um dispositivo (ex: Pixel 7).
  4. Selecione uma imagem de sistema (ex: Level 34 - Android 14).
  5. Finalize e clique no "Play" para iniciar o celular virtual.

5. Solução de Problemas ⚠️

  • VT-x is disabled: Você precisa habilitar a virtualização na BIOS do seu computador.
  • Studio muito lento: Adicione a pasta do projeto e as pastas do Android SDK nas exclusões do seu Antivírus.

Setup 02: Xcode (iOS Foundation) 🍎

O Xcode é a ferramenta necessária para compilar e testar apps iOS.

Important

O Xcode requer um computador Mac (macOS).

1. Instalação

  1. Abra a App Store no seu Mac.
  2. Pesquise por Xcode.
  3. Clique em Obter/Instalar.
  4. Após o download, abra o Xcode para carregar os componentes adicionais do macOS.

2. Configurando Simuladores

  1. Vá em Settings > Platforms.
  2. Verifique se o componente "iOS" está baixado.
  3. Se não estiver, clique em "GET" para baixar a versão mais estável.

3. Comandos de Linha (CLI)

Para que ferramentas de automação funcionem, você precisa instalar os Command Line Tools: 

xcode-select --install

4. Opcional: CocoaPods

Muitos projetos iOS antigos ainda usam CocoaPods para dependências: 

sudo gem install cocoapods

5. Solução de Problemas ⚠️

  • Espaço em Disco: O Xcode é muito grande. Garanta pelo menos 40GB de espaço livre para ele e os simuladores.
  • Build Lento: Use simuladores de modelos mais simples (ex: iPhone SE) para poupar memória RAM se necessário.

Sobre

Sobre o Curso

🎓 Desenvolvimento Frontend com Angular

Este curso foi projetado para capacitar desenvolvedores na criação de SPAs (Single Page Applications) modernas, utilizando o framework Angular do Google. O diferencial é a transição guiada da arquitetura clássica (NgModule) para o modelo moderno e otimizado baseado em Standalone Components.

🎯 Objetivos do Curso

  • Ecossistema Angular --- Compreender a estrutura de projetos, o papel do Angular CLI e a arquitetura baseada em componentes.

  • Manipulação Dinâmica --- Dominar todos os tipos de Data Binding e o uso de diretivas para criar interfaces ricas e interativas.

  • Modernidade Standalone --- Aprender a desenvolver aplicações sem NgModules, simplificando o código e melhorando a performance.

  • Integração Reativa --- Consumir APIs REST de forma profissional utilizando RxJS e as melhores práticas de serviços injetáveis.

📚 O Que Você Vai Aprender

Módulo 1 – Fundamentos e Estrutura

  • Ciclo de vida de um componente
  • Instalação e uso avançado de CLI
  • Arquivos principais (angular.json, main.ts)
  • Templates e estilização isolada

Módulo 2 – Core e Comunicação

  • Hierarquia Pai-Filho (@Input/@Output)
  • Serviços Singleton e DI
  • Diretivas Personalizadas
  • Roteamento e Lazy Loading

Módulo 3 – Standalone e Formulários

  • BootstrapApplication e provideRouter
  • Refatoração de código legado para Standalone
  • Validações síncronas e assíncronas em Forms
  • HttpClient e tratamento de erros

Módulo 4 – RxJS e Deploy

  • Operadores Pipe, Map, Filter
  • BehaviorSubject para estados locais
  • Angular Material e Design System
  • Deploy em plataformas modernsas (Firebase/Vercel)

🛠️ Metodologia

Abordagem "Learning by Doing". Cada aula inclui uma seção teórica consolidada, exercícios progressivos e a construção incremental de um projeto que fará parte do seu portfólio profissional.

Pronto para ser um especialista Angular? Começar Agora

Roadmap do Projeto: Frontend com Angular 🚀

Este documento rastreia a evolução do curso.

✅ Fase 1: Planejamento (Concluído)

  • Definição Syllabus (16 Aulas)
  • Transição para Standalone Components (Angular 15+)
  • Configuração MkDocs Material com layout de cards

✅ Fase 2: Conteúdo Base (Concluído)

  • Criação das 16 Aulas (Markdown)
  • Criação dos 16 Quizzes (HTML)
  • Criação dos 16 Conjuntos de Exercícios
  • Criação dos 16 Slides (RevealJS)

✅ Fase 3: Projetos e UX (Em Andamento)

  • Definição dos 16 Projetos práticos
  • [/] Diagramação Mermaid de arquitetura Angular
  • Exemplos de integração HTTP reativa

🚀 Fase 4: Lançamento e Deploy

  • Build e Deploy Gh-pages
  • Validação de links e acessibilidade
  • Publicação do Projeto Final

Status Atual: Em Refatoração Última Atualização: 21/02/2026

Materiais Complementares 📚

Bem-vindo à seção de materiais complementares do curso de Desenvolvimento Frontend com Angular. Aqui você encontra recursos adicionais para apoiar seus estudos e aprofundar seu conhecimento técnico.

  • Slides

    • Acompanhe o conteúdo teórico com slides dinâmicos e modernos.

  • Exercícios

    • Pratique a criação de componentes e lógica Angular.

  • Quizzes

    • Valide seu aprendizado com testes rápidos por aula.

  • Projetos

    • Construa aplicações reais do zero ao deploy.

  • Ambiente

    • Guias de instalação (Node.js, CLI, VS Code).

  • Docs Oficial

    • Documentação oficial do Angular para consulta.

🏷️ Índice de Tags Didáticas

Navegue pelas aulas, exercícios e projetos do curso organizados por temas, tecnologias e conceitos fundamentais:

tags.md:145-167/name

Versão para Impressão

Esta página foi gerada automaticamente para impressão.