Chegou a hora de juntar tudo o que aprendemos até aqui. Vamos juntar os conceitos que já aprendemos sobre Rotas e MVC e construirmos nossa primeira requisição. Este será um passo importante, pois será a primeira requisição que criaremos para a nossa aplicação e ela terá toda a base para as demais requisições.

Começaremos simples, nossa primeira requisição seguirá o modelo abaixo:

Faremos uma requisição do tipo GET, para o path status, que deverá ser processada pelo StatusController e por fim renderizar uma view. Mas antes de começarmos, vamos configurar o nosso ambiente.

Configurando o ambiente

Para configurar o nosso ambiente utilizaremos o Docker. Para isso precisaremos criar os seguintes arquivos:

Dockerfile

FROM ruby:3.1.0-slim

RUN apt-get update && apt-get install -y --no-install-recommends \\
    build-essential \\
    libpq-dev \\
    postgresql-client \\
    git \\
  && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

RUN gem install rails
WORKDIR /project

COPY Gemfile Gemfile.lock /project/
RUN bundle install

EXPOSE 3000

CMD ["bundle", "exec", "rails", "s", "-b", "0.0.0.0"]

docker-compose.yml

version: "3.1"

services:
  app:
    container_name: blog-api
    image: blog-api
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ./:/project
      - gems:/.gems
    environment:
      - SECRET_KEY_BASE=development
      - RAILS_ENV=development
      - DATABASE_NAME=blog-api
      - DATABASE_HOST=postgres
      - DATABASE_USERNAME=postgres
      - DATABASE_PASSWORD=postgres
      - API_HOST=localhost:3000
    stdin_open: true
    tty: true
    ports:
      - 3000:3000
  postgres:
    image: postgres:13.0-alpine
    environment:
      POSTGRES_PASSWORD: postgres
    ports:
      - "5432:5432"
    volumes:
      - postgres:/var/lib/postgresql/data

volumes:
  postgres:
  gems:

E mais dois arquivos vazios: Gemfile e Gemfile.lock. Esses arquivos serão substituídos futuramente.

Com todos os arquivos criados, dentro do mesmo diretório, podemos inicializar o nosso container com o seguinte comando:

docker compose run app bash

O comando acima irá nos conectar no container e quando estivermos conectado veremos algo assim:

No terminal iremos inserir os comando para gerar uma nova aplicação rails, com banco de dados PostgreSQL e em modo API:

rails new . -d postgresql --api

Agora iremos alterar o arquivo de configuração do nosso banco de dados que fica em config/database.yaml

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  host: <%= ENV.fetch("DATABASE_HOST") %>
  database: <%= ENV.fetch("DATABASE_NAME") %>
  username: <%= ENV.fetch("DATABASE_USERNAME") %>
  password: <%= ENV.fetch("DATABASE_PASSWORD") %>

development:
  <<: *default

test:
  <<: *default

production:
  <<: *default

Por fim, como último passo da configuração do nosso ambiente, iremos fazer uma limpeza no nosso Gemfile, deixando apenas as dependências que iremos utilizar:

source "https://rubygems.org"
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

ruby "3.1.0"

gem "rails", "~> 7.0.4", ">= 7.0.4.1"
gem "pg", "~> 1.1"
gem "puma", "~> 5.0"
gem "jbuilder"
gem "bootsnap", require: false

Executando nossa aplicação

Se tudo foi configurado corretamente, para executarmos nossa aplicação basta executarmos o seguinte comando:

docker compose up

Se tudo funcionar corretamente, você deverá ver a seguinte saída no terminal:

Agora é hora de acessar a nossa aplicação no navegador no endereço http://localhost:3000 e deveremos encontrar a seguinte página:

Aqui, nesta tela de erro, temos uma das lições mais importantes do desenvolvimento com Ruby on Rails: Leiam as mensagens de erro.

Na mensagem acima podemos ler “Não foi possível encontrar o banco de dados blog-api.” E mais abaixo instruções para cria-lo executando o comando rails db:create ou clicando no botão “create database”, que será a opção que utilizaremos.

Após clicar no botão, teremos a tela inicial do Ruby on Rails:

Criando nossa requisição

Construiremos nossa aplicação seguindo o diagrama e os arquivos citados acima, começando pelo arquivo de rotas.

Routes

Como vimos no artigo anterior, nossas rotas são definidas no arquivo config/routes.rb, e temos inúmeras formas de defini-las. Vamos pelo caminho mais simples, escrevendo nossa primeira rota da seguinte forma:

Rails.application.routes.draw do
  get '/status', controller: :status, action: :index
end

Seguindo as instruções acima, falamos para a nossa aplicação que ao acessarmos a url /status com um verbo GET (como o enviado pelo navegador). Queremos acessar o conteúdo da index do controller status.

Ao tentarmos acessar http://localhost:3000/status.json no navegador encontrarmos o nosso seguinte erro e uma pista para onde devemos seguir:

A mensagem de erro nos informa da ausência de uma constante (nesse caso uma classe) com o nome StatusController. Então vamos para ele.

Controller

Para criar o nosso controller teremos que obedecer algumas regras, chamadas de convenção, adotadas pelo framework. Muitas dessas convenções irão nos restringir e nos tirar o peso de algumas decisões, mas entenderemos melhor sobre elas ao longo do caminho, por hora é importante que saibamos as seguintes convenções:

• O controller deverá ser criado no diretório app/controllers
• O nome do arquivo do controller deve ter o sufixo _controller e terminar com a extensão .rb
• Dentro deste arquivo deverá ter uma class com o mesmo nome do arquivo, mas escrita em PascalCase. Exemplo: se o arquivo se chamar products_controller.rb a classe deverá ser ProductsController; se o arquivo se chamar home_controller.rb a classe deverá ser HomeController.
• O controller deverá herdar, direta ou indiretamente, da classe ActionController

Com essas regras em mente e já sabendo que o controller que queremos se chama StatusController, sabemos o nome do arquivo e onde ele deve ser criado. Aqui está o nosso arquivo app/controllers/status_controller.rb até o momento:

class StatusController < ApplicationController
end

Note que neste caso herdamos da classe ApplicationController e ela herdará da class ActionController, nos dando espaço para modificações e implementação em um escopo maior.

Novamente ao tentarmos acessar a url no navegador iremos nos deparar com um outro erro, que nos indicará a próxima implementação a ser feita:

Uma action com o nome index não foi encontrada em nosso controller.

Action

Como vimos neste artigo, uma action é um método que pode ser chamado através de uma rota e é obrigatório que renderize uma resposta ao usuário. Então vamos voltar ao nosso controller e adicionar o seguinte bloco de código:

class StatusController < ApplicationController
  def index
    render json: { status: 'ok' }
  end
end

Com o marcador def, criamos um novo método, nomeado index e este retornará, em formato json, o objeto contendo a chave status e o valor ok. Acessando nossa página no navegador deveremos ter o conteúdo exibido corretamente desta vez.

View

Por fim, nos resta apenas substituirmos o método render utilizado acima, pela substituição de uma view propriamente dita. Uma view também tem algumas convenções:

• Deve ficar localizada em app/views/nome_do_controller/. Exemplo, no caso do controller ProductsController (products_controller.rb), suas views ficariam localizadas em app/views/products/; No caso do HomeController (home_controller.rb) suas views ficariam localizadas em app/views/home/
• As views terão o mesmo nome da action que ela representa. No nosso exemplo, a action é a index do controller status, logo deve ficar em app/views/controllers/index.json.jbuilder
• No caso das nossas views em json, elas terão duas extensões .json e .jbuilder. O JBuilder é quem irá traduzir o nosso código Ruby para Json.

Iremos remover a linha com a instrução render do nosso controller e nosso arquivo app/views/status/index.json.jbuilder ficará com o seguinte conteúdo:

json.title "Blog API"
json.status :ok

Ao acessar a URL, finalmente teremos nosso conteúdo renderizado, encerrando nosso primeiro ciclo Rota → Controller → View.

No próximo artigo iremos nos aprofundar um pouco mais nos controllers e conhecer um pouco do mágica do Ruby on Rails. Se você gostou deste texto, clique no link abaixo e receba uma notificação sempre que eu publicar um novo texto por aqui!

Get an email whenever João Mateus Scarpa publishes.

Se você tiver seguindo a série, tiver algum problema para seguir algum passo ou se quiser falar comigo, só enviar um e-mail para joao.scarpa@gmail.com

Aprendendo Ruby on Rails #4: Hello World was originally published in Designa Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

No último artigo desta série nos concentramos na arquitetura MVC e agora, chegou a hora de entendermos como podemos fazer as nossas requisições chegarem aos nossos models e controllers, e obtermos as nossas views como respostas.

Mapear URLs e requisições para dentro da nossa aplicação, da forma correta e para o lugar exato que desejamos, é uma habilidade imprescindível para nossa jornada como desenvolvedores web, afinal, toda a internet funciona através de requisições e rotas. Portanto, vamos entender o que são rotas e como elas funcionam no Ruby on Rails.

O que são rotas?

Uma rota é um mapeamento de uma URL e um verbo HTTP para uma ação de algum controller. Simples assim!

Quando uma URL é acessada através de um navegador, na maioria das vezes, estamos fazendo uma requisição do tipo GET (com o verbo HTTP GET), pois o nosso intuito é buscar informações em um servidor. Porém os verbos HTTPS são múltiplos e usados para funções específicas. Para esta série podemos nos focam nos seguintes verbos e funções apenas:

Para cada rota que declaramos no Rails, precisaremos indicar, além do verbo e da url, qual ação a ela executar e para isso poderemos usar o conjunto controller + action. Por exemplo, quando o usuário entra em um URL /posts em um navegador, o Rails deve identificar a rota (GET + /posts) e enviar para o controller posts na action index , por exemplo.

Para as actions, aqui vale a dica das 7 ações “padrão”. Na maioria dos casos (99%) todas as nossas actions ficarão dentro do conjunto abaixo e raramente precisaremos de outras. São elas:

Criando rotas

Nossas rotas serão definidas no arquivo config/routes.rb, onde possuímos muitas formas de declará-las. Podemos declarar a rota get ‘/posts’, to: ‘posts#index’ que mapeia a URL /posts para a ação index no controller posts, por exemplo, mas também podemos declará-la com a construção resources :posts, only: [:index], portanto neste momento não nos focaremos nas diferenças das declarações e buscaremos apenas seguir um dos caminhos e nos mantermos nele de forma constante.

Aqui estão algumas formas de definir a mesma rota:

# Utilizando resources
resources :posts, only: [:index]

# Utilizando um bloco
controller :posts do
	get '/posts', action: :index
end

# Inline
get '/posts', controller: :posts, action: :index
get '/posts', to: "posts#index"

Neste ponto já deve ter ficado claro, mas vale ressaltar que as rotas são extremamente importantes para o funcionamento da nossa aplicação, pois elas são como as veias do nosso corpo e as trilhas um chip de computador. Elas são quem definem o fluxo da aplicação e também quais as URLs que estarão disponíveis para o usuário, mas também podem ser usadas para monitoramento, automação e muito mais.

No próximo artigo, iremos criar nosso “Hello World”, juntando tudo o que aprendemos até aqui. Uniremos os conceitos fundamentais de Rotas e MVC para construirmos nossa primeira requisição. Este será um passo importante, pois será a primeira requisição que criaremos para a nossa aplicação e ela terá toda a base para as demais requisições. Por isso, é importante compreendermos ao máximo cada um dos conceitos abordados até aqui para que possamos criar uma aplicação robusta e eficiente.

Se você gostou deste texto, clique no link abaixo e receba uma notificação sempre que eu publicar um novo texto por aqui!

Get an email whenever João Mateus Scarpa publishes.

E se quiser falar comigo, só enviar um e-mail para joao.scarpa@gmail.com

Aprendendo Ruby on Rails #3: Rotas was originally published in Designa Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Na primeira publicação desta série vimos que o Ruby on Rails é um framework para desenvolvimento web que se baseia na arquitetura Model-View-Controller (MVC) que, como o nome sugere, divide a aplicação web em três partes: o modelo, a visualização e o controlador. Neste artigo, vamos nos concentrar no entendimento da arquitetura MVC e como ela se encaixa na estrutura do Ruby on Rails.

Models

O Model é, sem dúvida, um dos principais componentes da nossa aplicação. É a partir dele que aplicamos as validações e definimos os relacionamentos entre os nossos recursos, criamos regras de negócio e muito mais. Além disso, no Ruby on Rails, alguns Models podem estar vinculados direto ao nosso banco de dados através do ActiveRecord (O ORM padrão do Rails)

Um Model é definido por uma classe definida em um arquivo homônimo, criado dentro do diretório app/models. O arquivo abaixo poderia representar um modelo de usuários, por exemplo:

class User
  attr_reader :username, :email
  
  def admin?
    # Apply some rule
  end
end

View

Uma view, como o nome sugere, é responsável por exibir informações para os usuários. Ela pode ser usada para exibir informações em um formulário, produtos em uma página de detalhes, etc. Normalmente, as views são representadas por arquivos HTML, mas nesta série abordaremos a utilização do Ruby on Rails na criação de API’s, portanto nossas views serão representadas por arquivos JSON.

Todas as nossas views serão criadas em app/views dentro do diretório do seu respectivo controller.

Controller

Por fim, o controller é responsável por processar as solicitações do usuário e enviar as informações corretas para o model (quando necessário) e para a view, no retorno ao usuário. Um controller, por exemplo, pode ser o meio onde um formulário de cadastro de usuário será processado e salvo.

Eu particularmente gosto de pensar no controller como uma ponte entre as demais partes da aplicação, pois ele é o responsável por usar nossas requisições para os models e para as views. Nosso controller ficará dentro do diretório app/controllers.

Um controller também é representado por um classe, mas desta vez com um sufixo (Controller) em seu nome e no nome do arquivo e com uma herança predefinida (ele deve possuir o ActionController em sua cadeia de herança).

No exemplo abaixo o nosso controller herda de uma classe ApplicationController e essa classe herda diretamente do ActionController, fazendo assim nosso UsersController tê-lo em sua cadeia de herança:

class UsersController < ApplicationController
  #...Controller definition
end

Dentro dos nossos controllers, existem dois tipos de métodos: os métodos comuns e as actions. Ambos possuem a mesma estrutura e definição, variando apenas em seu propósito. Uma action é um método que pode ser chamado através de uma rota e é obrigatório que renderize uma resposta.

A arquitetura MVC é a base fundamental da estrutura do Ruby on Rails. Compreender como cada parte se comunica é crucial para o desenvolvimento de aplicações web com Ruby on Rails. No próximo artigo iremos falar um pouco sobre as Rotas e entender um pouco mais sobre a arquitetura do Ruby on Rails e como podemos juntar todas essas peças para construir uma aplicação.

Se você gostou deste texto, clique no link abaixo e receba uma notificação sempre que eu publicar um novo texto por aqui!

Get an email whenever João Mateus Scarpa publishes.

E se quiser falar comigo, só enviar um e-mail para joao.scarpa@gmail.com

Aprendendo Ruby on Rails #2: Arquitetura MVC was originally published in Designa Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

O Docker é um dos mais populares sistemas de contêineres de software. Ele permite que os desenvolvedores criem, implantem, testem e executem aplicativos de maneira rápida e confiável.

Mas enfim… o que é Docker?

O Docker é uma plataforma de software projetada para permitir que os desenvolvedores empacotem seu código em contêineres, o que significa que eles podem empacotar tudo o que é necessário para executar o aplicativo em um único pacote. Isso inclui o código, dependências, bibliotecas, configurações e outros recursos. Esse pacote pode então ser facilmente implantado em qualquer ambiente, seja local ou na nuvem.

Por que usar o Docker?

Entre os diversos benefícios, um dos principais é o auxilio na redução dos problemas de compatibilidade em diferentes ambientes, seja em desenvolvimento ou em produção.

Além disso, os contêineres Docker são muito mais leves que as máquinas virtuais, o que significa que você pode executar mais contêineres com maior eficiência e economia de recursos.

Como o Docker funciona?

O Docker usa os recursos de gerenciamento de contêineres do sistema operacional para criar um ambiente de execução para os contêineres. Ele também cria um sistema de arquivos compartilhado para acessar os arquivos necessários para executar aplicativos. O Docker também fornece um conjunto de ferramentas para facilitar a implantação, gerenciamento e atualização dos contêineres.

Rodando uma aplicação Ruby on Rails

Para executaramos, por exemplo, uma aplicação Ruby on Rails podemos utilizar uma imagem base em um Dockerfile, como a do exemplo a seguir:

FROM ruby:3.1.0

RUN apt-get update -qq && apt-get install -y nodejs postgresql-client
RUN mkdir /myapp

WORKDIR /myapp

COPY Gemfile /myapp/Gemfile
COPY Gemfile.lock /myapp/Gemfile.lock

RUN bundle install

COPY . /myapp

CMD ["rails", "server", "-b", "0.0.0.0"]

E para executar nossa aplicação dentro deste contêiner, basta executarmos o seguinte comando:

docker run -p 3000:3000

Por ser uma plataforma de software versátil que permite que os desenvolvedores criem e implantem aplicativos de maneira rápida e confiável, ele reduz os problemas de compatibilidade e oferece um método eficiente para executar aplicativos em servidores locais e na nuvem. Além disso, o Docker permite que os desenvolvedores gerenciem facilmente seus contêineres com ferramentas simples e intuitivas.

Gostou do conteúdo?

Se você gostou deste texto, clique no link abaixo e receba uma notificação sempre que eu publicar um novo texto por aqui!

Get an email whenever João Mateus Scarpa publishes.

E se quiser falar comigo, só enviar um e-mail para joao.scarpa@gmail.com

Introdução ao Docker was originally published in Designa Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Aprendendo Ruby on Rails #1: O que você deveria saber antes de começar

“Learn just what you need to get started, then keep leveling up as you go.”

“Aprenda apenas o que precisa para começar e depois continue evoluindo à medida que avança”. Este é um dos mantras e um dos grandes diferencias do (meta-)framework Ruby on Rails.

Exibido a primeira vez em 2003 por seu criado DHH, o Ruby on Rails é um framework de desenvolvimento web que usa a linguagem Ruby em sua base, ampliando e seguindo as diretrizes da linguagem, sendo focado no desenvolvedor e na facilidade e prazer em codificar.

Muitas vezes chamados simplesmente de Rails, ele é, tecnicamente, um meta-framework, ou seja, um framework formado por outros frameworks, onde podemos destacar algumas peças importantes como ActiveRecord, ActionController, ActionMailer, ActionPack, ActionSupport, etc…

O framework, que trabalha com a arquitetura MVC, pode ser utilizado desde a criação de API’s até a criação FullStack (com HTML, CSS e Javascript sendo renderizados pelo servidor). As duas abordagens compartilham praticamente 80% de código em comum, variando apenas com relação aos arquivos de view. Durante esta série abordaremos exclusivamente a utilização do Rails para a criação de API’s

Convention over configuration & DRY

Sem dúvidas as duas principais características desta caixa de ferramentas que é o Ruby on Rails, e que estão intrinsecamente ligadas é o conceito e convenção sobre configuração (do inglês, CoC) e o de Não se Repita (do inglês, DRY).

Enquanto o conceito DRY diz a respeito a redução de repetição pela utilização de abstrações, o principio de convenção sobre a configuração nos ensina a utilizar as convenções pré-definidas a fim de reduzir a quantidade de código escrita, priorizando as regras já definidas pelo framework. Por exemplo, ao definir uma tabela users com os campos id, name e mail, o model vinculado a essa tabela não terá a necessidade de definir getters e setters para os 3 campos, pois já foram definidos e não precisamos repetir (DRY). Ainda no mesmo exemplo, esperamos que a tabela users seja representada pelo modelo User (o mesmo nome da tabela, no singular) pois esta é a convenção pré-estabelecida pelo framework. (CoC). É importante dizer que essa convenção pode ser sobrescrita, pois aqui o intuito maior não é limitar o usuário e sim facilitar o dia a dia de quem puder e escolher seguir as convenções.
(Afinal… escrevendo menos código temos menos chance de criarmos bugs 😉)

Por mais que eu tente me manter neutro com relação a tecnologias e linguagens na maior parte do tempo, não tem como negar o meu apego profissional e emocional com Ruby e com Ruby on Rails.

Mesmo estudando e trabalhando com programação há quase 15 anos, eu marco o início oficial da minha carreira na área de software (seja como programador, tech lead, consultor ou educador) quando conheci e comecei a me dedicar a essa linguagem e framework.

Poder trabalhar ensinando essa e outras ferramentas que foram importantes para minha carreira e plantar essa mesma semente que foi plantada em mim há 10 anos atrás é um prazer sem igual.

Gostou do conteúdo?

Se você gostou deste texto, clique no link abaixo e receba uma notificação sempre que eu publicar um novo texto por aqui!

Get an email whenever João Mateus Scarpa publishes.

E se quiser falar comigo, só enviar um e-mail para joao.scarpa@gmail.com

Aprendendo Ruby on Rails #1 was originally published in Designa Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Depois de toda a teoria e conceitos chegou a hora de juntarmos tudo que vimos até aqui e construir nossa primeira aplicação. Para começarmos de forma simples, vamos construir uma aplicação de “To-do List”, onde o usuário poderá listar, adicionar e remover tarefas da sua lista. Bora lá!

Setup

Vamos começar a nossa aplicação com base no template disponível neste repositório. Aqui já temos uma aplicação com Angular e a estrutura necessária para executá-la em um container docker.

Nossa primeira modificação no projeto será colocar as dependências que iremos utilizar no arquivo app.module.ts. Adicionaremos 3 módulos: os dois de formulário e o cliente de Http.

Criando nossa página

Como nossa aplicação será bem simples, ela terá apenas uma página que será representada pelo TasksComponent que criaremos no diretório app/pages/tasks com o seguinte conteúdo inicial:

Agora para tornar nosso componente utilizável e o transformarmos de fato em uma página, precisamos declará-lo no app.module.ts e criar uma rota para o mesmo no arquivo app-routing.module.ts.

Após esses passos, já conseguimos visualizar nossa página no navegador:

Trabalhando o visual

Para nos auxiliar na questão visual da nossa página, iremos utilizar o Bootstrap através de um CDN para facilitar a instalação. Para isso adicionaremos a seguinte importação no arquivo index.html

Após importar o Bootstrap e adicionar alguns elementos HTML e classes no nosso componente, montamos a seguinte tela:

Buscando informações

Com nossa tela pronta, agora é hora de buscarmos as informações em nossa API e exibi-las na tela.

Nosso primeiro passo será importar e inicializar o nosso HTTP Client em uma variável através do método construtor do componente.

Com o HTTP Client disponível na variável httpClient, vamos implementar a interface OnInit em nosso componente e criar uma variável para armazenar os itens da nossa lista:

Notem que para definirmos o tipo da nossa variável tasks (linha 17) criamos uma interface com nome Task (linha 4) com os campos id, title e done.

Agora podemos, enfim, consultar a nossa API para buscar as informações.

Por fim, podemos utilizar a variável tasks para renderizar os itens na nossa lista no nosso HTML.

Gravando informações

Com nossa lista funcionando, chegou a hora de gravar os itens na nossa API, para fazer isso vincularemo o input da tela com um ngModel e ao clicarmos no botão Add iremos enviar uma requisição para API para criar uma nova tarefa.

De forma similar, iremos utilizar a diretiva (click) em nosso botão para chamar uma função do nosso componente chamada save()

Agora, vamos dar uma olhada na estrutura do nosso arquivo Typescript com a variável e a função save.

Note que na função save, não passamos tipo para o método post do HTTP Client pois esta chamada para API não possuí um retorno, logo, não precisamos atribuir um tipo para ela.

Outro ponto de atenção é nas ações realizadas após o envio das informações para a API: Resetamos o valor da variável newTask e chamamos a função loadTasks para recarregar a lista de tarefas na tela.

Excluindo tarefas

Para realizarmos a exclusão de tarefas da lista, vamos alterar nosso HTML e inserir um botão de excluir para cada tarefa da nossa lista.

No nosso TS, criaremos a função deleteTask da seguinte forma:

Atualizando a tarefa

Avançando em nossa aplicação, chegou a hora de conseguirmos marcar as atividades como feitas ou não feitas e essas modificações serão atualizadas em nossa API e nossa tela irá reagir a essas mudanças.

Vamos começar com as mudanças em nossa tela: toda vez que uma tarefa estiver marcada como finalizada iremos exibi-la com outra cor e tachada.

Vamos dar uma olhada em como ficou nosso HTML para criar esse efeito

Aqui no HTML temos alguns pontos interessantes:

• Linha 11: Utilizamos a diretiva [checked] para marcar o checkbox caso a propriedade done da tarefa tenha o valor verdadeiro.
• Linha 11: utilizamos a diretiva (change) para chamar a função toggleTask toda vez que o input tiver seu valor alterado. Essa função receberá a própria tarefa como parâmetro.
• Linha 12: Utilizamos a diretiva [class.] para aplicar a classe done ao label caso a propriedade done da tarefa tiver um valor verdadeiro.

No nosso arquivo TS temos a adição da função toggleTask com o seguinte conteúdo:

A função toggleTask receberá uma tarefa como parâmetro, irá inverter o valor da propriedade done da tarefa e então realizará uma chamada para a API com o método patch passando no payload a chave done e o seu novo valor. Aqui como não nos importar o retorno da API não utilizaremos a construção com o then encerrando nossa chamada no método toPromisse().

Aplicação funcionando

Por fim, podemos ter uma visão da nossa aplicação funcionando no vídeo abaixo:

Gostou do conteúdo?

Se você gostou deste texto, clique no link abaixo e receba uma notificação sempre que eu publicar um novo texto por aqui!

Get an email whenever João Mateus Scarpa publishes.

E se quiser falar comigo, só enviar um e-mail para joao.scarpa@gmail.com

Aprendendo Angular #12: Construindo uma aplicação single-page was originally published in Designa Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Da mesma que precisamos importar alguns módulos para trabalhar com formulários, para realizarmos chamadas para uma API, também precisaremos importar alguns módulos específicos para nossa a aplicação. Mas antes de partirmos para o código, desta vez, precisamos de um pouco de teoria.

Verbos HTTP

Quando trafegamos informações entre nossas aplicações Front-End (Cliente) e Back-end (Servidor) através do protocolo HTTP, essas requisições sempre serão precedidas por um verbo HTTP, que indicará para o servidor a intenção daquela requisição a deixando mais explicita e semântica. Os principais verbos HTTP com suas respectivas funções são:

• GET: Utilizado para obter informações do servidor, geralmente não utiliza parâmetros, mas pode recebê-los via query string.
• POST: Utilizado quando queremos criar algum recurso no servidor (ex: realizar um cadastro de informação). Geralmente vai receber um conjunto de dados no corpo da requisição, ao qual damos o nome de payload.
• PATCH: Tem o funcionamento muito parecido com o do POST, porém é utilizado com o intuito de atualizar uma informação já existente no servidor. Geralmente também receberá informações no corpo da requisição.
• DELETE: Por fim, como o nome sugere, a utilização do verbo DELETE, é feita quando desejamos realizar a exclusão de um recurso do servidor. Também pode receber informações no corpo da requisição mas é menos comum.

Códigos de status

Uma outra parte muito importante das requisições web é a identificação das suas respostas e isso se dá através dos códigos de status. Para cada tipo de resposta, teremos um código específico (ou quase isso), sendo os mais conhecidos e mais utilizados os seguintes:

• Códigos da linha 200: Indicam sucesso na requisição, os mais utilizados são os 200 (ok) e o 201 (recurso criado)
• Os códigos da linha 400: Esses códigos indicam que algo aconteceu de inesperado na requisição e ela não pode ser finalizada com sucesso. Os mais utilizados são: 400 (Má requisição), 401 (Não autorizado), 403 (Acesso restrito), 404 (Recurso não encontrado) e 422 (Entidade não processada)
• Os códigos da linha 500: São erros que acontecem no servidor e geralmente indicam algum problema no código ou infraestrutura do mesmo. Os mais utilizados são 500 (erro interno), 503 (Serviço indisponível) e 504 (Timeout)

Com essa parte da teoria explicada, vamos colocar a mão no código! O módulo que utilizaremos para fazer as chamadas HTTP será o HttpClientModule, do pacote @angular/core/http, da seguinte maneira:

Um exemplo de componente realizando uma chamada para api, ficaria da seguinte maneira:

Sobre esta sintaxe é importante repararmos nos seguintes pontos:

• O HttpClient deve ser inicializado no método construtor do componente;
• Em sua utilização escolhemos o verbo/método (no caso acima foi o get) e devemos definir o tipo do retorno entre < >. Este tipo será atribuído para a variável data, no retorno da promise;
• O método chamado no httpClient (get, post, delete, patch) retornará um Observable, que iremos transformar para uma promise e então acessaremos o seu valor com as instruções then e/ou catch
• Os métodos get, post, patch e delete no httpClient recebem obrigatoriamente uma URL como primeiro parâmetro e podem receber um objeto como segundo parâmetro: No get este objeto será transformado em queryString e nos demais métodos serão considerados payload da requisição.

Gostou do conteúdo?

No próximo artigo, vamos utilizar tudo que vimos até aqui para construir uma aplicação de uma página.

Se você gostou deste texto, clique no link abaixo e receba uma notificação sempre que eu publicar um novo texto por aqui!

Get an email whenever João Mateus Scarpa publishes.

E se quiser falar comigo, só enviar um e-mail para joao.scarpa@gmail.com

Aprendendo Angular #11: Primeira requisição para API was originally published in Designa Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Para interagir de forma mais dinâmica com o usuário, nossa aplicação precisa ser capaz de receber informações do usuário para processarmos e a forma mais fácil de fazermos isso em uma aplicação web é através da entrada de informações por formulários.

Em Angular temos duas principais formas de interagir com os formulários e acessarmos os valores digitados pelo usuário: através da diretiva ngModel ou pela construção de um FormGroup e FormControl.

Independente de qual caminho vamos seguir, precisaremos importar dois módulos do pacote @angular/forms em nosso app.module.ts

ngModel

Quando a nossa entrada de informações não está vinculada a um formulário podemos usar a diretiva ngModel para facilitar o acesso a informação inserida pelo usuário. Essa diretiva irá conectar o componente de entrada (input, select, textarea, etc..) diretamente com uma variável pública daquele componente. A diretiva, por ser um vinculo de mão dupla (two-way data binding) será utilizado com a notação denominada banana box como demonstada abaixo:

FormGroup e FormControl

Uma forma mais robusta de acessarmos e manipularmos os dados inseridos pelo usuários é através da utilização de FormGroups e FormControls. Essas duas estruturas serão utilizadas em conjunto. Enquanto o FormGroup representa o formulário como um todo, o FormControl representará um campo de entrada de do usuário.

Sua utilzação será feita tanto no arquivo de typescript quanto no arquivo de HTML da seguinte forma:

Apesar da construção ser mais verbosa, ela nos trás alguns benefícios como a possibilidade de validação dos campos e do formulário, a entrada de valores padrão de forma mais simples e a capacidade de agrupamento das informações de forma “automática”.

Vejamos alguns exemplos da utilização dessa funcionalidades do formulário.

Validações

Sempre que definirmos um novo FormControl, podemos passar duas informações para seu construtor: o valor inicial e um vetor com validações para aquele campo:

Desta forma, através do objeto form podemos utilizar o método valid para saber se todos os campos estão de acordo com as validações antes de utilizarmos de fato os valores:

Acessando os valores

Para acessar os valores do formulário, também podemos fazer de forma simples, através da propriedade value objeto form, da seguinte forma:

Gostou do conteúdo?

No próximo artigo, vamos finalmente aprender a interagir com com uma API e obter informações diretamente do nosso servidor.

Aprendendo Angular #11: Primeira requisição para API

Se você gostou deste texto, clique no link abaixo e receba uma notificação sempre que eu publicar um novo texto por aqui!

Get an email whenever João Mateus Scarpa publishes.

E se quiser falar comigo, só enviar um e-mail para joao.scarpa@gmail.com

Aprendendo Angular #10: Formulários was originally published in Designa Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Muitas vezes em nossas aplicações temos a necessidade de compartilhar informações através de muitos componentes e a melhor forma de fazermos isso em nossas aplicações é através de uma estrutura nomeada Service. Além de fornecer acesso à essas informações ela auxiliar a organizarmos nosso código e permitir que nossos componentes fiquem responsáveis apenas pela apresentação dos dados.

Criando nosso primeiro service

Seguindo a organização da nossa aplicação, iremos criar um diretório services, dentro do diretório app e inicializar um arquivo nomeado auth.service.ts com o seguinte conteúdo:

Quando decoramos nossas classe com o marcador Injectable deixamos essas classe pronta para o sistema de injeção de dependências do Angular, o que nos permitirá a utilizá-la através dos construtores dos nossos componentes, da seguinte forma:

Compondo nosso service

Para centralizarmos as rotinas e as informações com relação a autenticação do usuário, iremos utilizar o localStorage e compor nosso service com as seguintes funções:

Gostou do conteúdo?

No próximo artigo, vamos aprender a manipular formulários e receber a entrada de informações do usuário.

Aprendendo Angular #10: Formulários

Se você gostou deste texto, clique no link abaixo e receba uma notificação sempre que eu publicar um novo texto por aqui!

Get an email whenever João Mateus Scarpa publishes.

E se quiser falar comigo, só enviar um e-mail para joao.scarpa@gmail.com

Aprendendo Angular #09: Separando nossas regras com Services was originally published in Designa Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.