Forem: Igor Oliveira

Criando uma plataforma do 0 - Dia 2

Igor Oliveira — Sat, 04 Nov 2023 14:06:14 +0000

Nesse segundo dia, eu fiz a parte de login e cadastro da aplicação e para facilitar a vida, fiz uso do Laravel Sanctun. O Laravel Sanctum já nos entrega um sistema de autenticação baseado em tokens para usar em nosso front end ou mobile. Dessa forma, cada usuário na nossa aplicação vai ter um token e o interessante é que esse token pode receber o que a documentação chama de escopo e habilidades. Onde podemos definir o que aquele tipo de token pode fazer e no seu escopo podemos definir a expiração token também.
Definido que iria usar o Sanctum, eu segui a documentação no site do próprio Laravel para fazer a instalação dele, mas a única que precisei fazer de fato que o Laravel não me entregou pronto, foi descomentar a linha \Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class que se estava no arquivo Kernel.php, para ter a certeza que as request que irão vir do nosso FrontEnd irão ser Stateful, isto vai dizer para nosso BackEnd manter o estado da nossa sessão.
Outra alteração que precisei fazer foi no arquivo de migration de o Laravel Sanctum gera para gente, no primeiro dia foi definido que a Chave Primária (PK) da nossa tabela de usuários seria um UUID e quando comecei a testar me deparei com um erro dizendo que uma coluna que a migration criou e iria guardar o ID do usuário não aceitava valor do tipo UUID, então a migration que era dessa forma:

Schema::create('personal_access_tokens', function (Blueprint $table) {
  $table->id();
  $table->morphs('tokenable');
  $table->string('name');
  $table->string('token', 64)->unique();
  $table->text('abilities')->nullable();
  $table->timestamp('last_used_at')->nullable();
  $table->timestamp('expires_at')->nullable();
  $table->timestamps();
});

Ficou dessa forma, a mudança ocorre na coluna tokenable, passamos a utilizar uuidMorphs para informar que a coluna irá aceitar tipos UUID:

Schema::create('personal_access_tokens', function (Blueprint $table) {
  $table->id();
  $table->uuidMorphs('tokenable');
  $table->string('name');
  $table->string('token', 64)->unique();
  $table->text('abilities')->nullable();
  $table->timestamp('last_used_at')->nullable();
  $table->timestamp('expires_at')->nullable();
  $table->timestamps();
});

Feito essa mudança, partiu agora criar nosso Controller para lidar com o Login e Cadastro dos usuários. Para isso é fácil, bastou rodar o comando php artisan make:controller Api/Auth/AuthController, esse comando irá criar um Controller dentro da pasta app/Http/Controllers/Api/Auth/AuthController.php.
Agora começa a parte boa, codar a lógica de primeiro de login do usuário e isso foi bem simples, primeiro eu faço a validação dos campos que quero receber, no login eu espero receber o e-mail e senha do usuário, esses dados vão ser do tipo string e obrigatórios, depois eu procuro se tem algum usuário com esse e-mail no banco de dados e faço a verificação se a senha está correta, feita essa primeira parte e tudo estiver ok, eu crio o token daquele usuário e retorno o usuário e o token como resposta.

public function login(Request $request): Response
{
  $data = $request->validate([
    'email' => 'required|string',
    'password' => 'required|string'
  ]);

   $user = User::where('email', $data['email'])->first();

  if (!$user || !Hash::check($data['password'], $user->password)) {
    return response([
      'message' => 'Email ou senha incorretos'
    ], 401);
  }

  $token = $user->createToken('apiToken')->plainTextToken;

  return response([
    'user' => $user,
    'token' => $token
  ], 200);
}

Lógica de login feita, basta só cadastrar a rota no arquivo routes/api.php e o login já está pronto.
Para cadastro a lógica é parecida, a diferença é que eu faço a validação também do primeiro e último nome e faço um regex na senha para ver se ela atende uma determinada condição e também já gero o token, porque o objetivo é assim que ele fizer o cadastro já cai dentro da plataforma para começar a usar.

Conclusão

Bom, nesse segundo dia foi isso, pretendo ainda melhor essa parte da geração do token, pois ele por padrão nunca expira e isso no objetivo que tenho em mente pode não ser bom, então as próximas partes eu irei colocar um tempo de expiração e também criar a rota para fazer o logout do usuário e apagar esse token no nosso banco de dados. Então é isso, devagar o sistema vai tomando forma e eu vou aprendendo cada vez mais!

Criando uma plataforma do 0 - Dia 1

Igor Oliveira — Sat, 04 Nov 2023 14:03:44 +0000

Aqui vou documentar todo o processo de criação de um sistema de ponta a ponta, desde o levantamento inicial, passando pela escolha de tecnologias, desenvolvimento do BackEnd, FrontEnd e deploy da aplicação.

Nesse primeiro dia, eu criei um mapa mental do objetivo e o fluxo básico da aplicação, descrevendo as tecnologias que vão ser usadas durante o desenvolvimento. Abaixo tem uma imagem desse mapa

O objetivo é simples, eu quero um lugar onde eu possa colocar o código de uma ação que comprei, a quantidade, o valor pago por cada ação e que caso queira fazer o upload da nota de corretagem, também seja possível. De começo é para ser algo simples e com o passar do tempo e conforme eu for estudando novas coisas, quero ir melhorando esse produto.

A escolha de tecnologias foi com base em gosto, eu gosto muito de PHP e principalmente do Laravel, banco de dados o escolhido foi PostgreSQL, pois queria tentar algo novo já que estou acostumado a usar MySQL como banco de dados e a AWS vai ser para usar o S3 para guardar as notas de corretagem. O FrontEnd ainda não decidi se vou usar algo novo ou algo que já estou acostumado como um NextJS da vida, mas isso vai ser decisão para ser tomada mais para frente.

Dia 1 - parte 2

Aproveitando o embalo, dei o start no projeto, comecei criando um projeto Laravel na minha máquina, usei o próprio exemplo do site para gerar o projeto. Também entrei no Hub do Docker para poder criar um container com o banco de dados Postgres.
Com o projeto gerado e o banco de dados de pé, eu fiz os seguintes passos:

Primeiro fui no meu arquivo .env e mudei as configurações para acessar o banco de dados. Coloquei o driver do Postgres que é o pgsql, mudei a porta já que o Postgres usa a 5432 e mudei o usuário e senha para os valores que coloquei quando levantei o container
Depois no arquivo de migrate que o próprio Laravel gera para o modelo de User (que ele também já gera sozinho) eu fiz umas mudanças, primeiro eu mudei para a coluna ser um UUID e ser a chave primária da tabela, também acrescentei os campos first_name e last_name, retirei a verificação obrigatória de e-mail e o campo remember_token. Com isso já estava na forma como planejei inicialmente, aí foi só rodar o comando php artisan migrate e pronto, já tenho minha tabela pronta.
Precisei fazer umas alterações no meu Model User, a primeira coisa foi colocar uma Trait HasUuid para falar para o nosso modelo que vamos usar UUIDs, também adicionei os campos novos dentro do array $fillable e removi os campos que eu não vou utilizar.
E para finalizar o Laravel fornece uma Factory já pronta para o nosso usuário, só precisei remover alguns campos que eu não irei utilizar e adicionar os novos e depois disso no meu arquivo DatabaseSeeder, eu fiz o uso do nosso modelo para gerar usuários automaticamente e rodei um php artisan db:seed para persistir os novos usuários no banco de dados.

Conclusão

Acho que para um primeiro dia está bom, a próxima parte vai ser fazer o CRUD de usuários e estou animado para continuar com o projeto!

Um Estudo Sobre Generics no TypeScript

Igor Oliveira — Thu, 07 Jul 2022 18:37:13 +0000

Um Estudo Sobre Generics no TypeScript

Um assunto que confunde muita gente no começo da caminhada com TypeScript, são os Generics.

Primeiro, vamos ver o que a documentação do TypeScript fala sobre os Generics:

“In languages like C# and Java, one of the main tools in the toolbox for creating reusable components is generics, that is, being able to create a component that can work over a variety of types rather than a single one. This allows users to consume these components and use their own types”

O trecho que mais interessa é: that is, being able to create a component that can work over a variety of types rather than a single one

Em uma tradução livre quer dizer que Generics são capazes de criar componentes que funcionam de várias formas ao invés de apenas uma, ou seja, podemos dizer que os Generics são para os tipos o que valores são para os argumentos de uma função.

A syntax de um Generic

Os Generics sempre são envoltos de **<>** e podem conter mais de uma Generic, veja os exemplos abaixo:

Geralmente, você verá as Generics sendo representadas por letras, isso foi uma convenção da comunidade. São elas:

T - para tipos (types)
S - para estados (state)
K - para chaves (key)
V - para valores (value)
E - para elementos (element)

Bom, se o intuito da Generic é ajudar na construção de componentes que podem ser reutilizados, vamos criar um componente que vai ser um wrapper do axios, para nos ajduar nas chamadas para APIs

Criando o componente

Nosso componente vai ser um cliente que recebe a url de uma API e faz um GET retornando um array, coisa simples, porém vai ser bem preciso para explicar como as Generics funcionam. Primeiro eu escrevi ele de uma forma engessada e aos poucos vamos refatorando ele

Primeiro vamos relatar alguns pontos que podem ser melhorados e ir ponto a ponto melhorando nosso componente.

Primeiro, a URL da nossa API está fixa no código e isso não é legal, já que eu quero um componente que possa ser utilizado de diversas formas e com diferentes APIs, eu teria que receber como argumento na função. Nosso código agora vai ficar assim:

Segundo ponto, estamos usando TypeScript, porém nosso retorno não está tipado. Se fizermos response.data[0]. não teremos a inteligência do nosso editor para nos ajudar com o autocomplete e como fazemos a tipagem? Aqui vamos começar a ver os Generics sendo usados, o Axios permite o uso de Generics para que possamos tipar o retorno da nossa chamada e para isso basta passarmos nossa tipagem para axios.get<Type>(). Nosso código agora fica assim:

Nosso código já está bem tipado, falamos que o retorno da nossa chamada vai ser um array do tipo Props e assim está bem legal nosso código já. Mas temos um problema, o que acontece se eu passar uma outra URL? O tipo que criamos só serve para um tipo de retorno e é ai que vamos entrar no uso das Generics, vamos deixar nosso código pronto para o uso das Generics:

Vou tentar explicar o que fiz nesse ponto 3, lembrando que lá em cima em disse que algumas letras a comunidade usa para representar as Generics, aqui eu passei <T> para indicar que vamos repassar um tipo para a nossa função e depois para o axios. No código abaixo vamos ver como usamos nosso Client.

Por debaixo dos panos

Para resumir o que o Generics faz por debaixo dos panos, é como se a gente tivesse uma função que recebe alguns parâmetros e essa função faz algo com esses parâmetros, no caso ele vai pegar o <Props[]> e vai colocar onde está <T> fazendo com os tipos sejam o que passamos no Generic de quando instanciamos nosso client. Abaixo vou deixar um GIF que me ajudou a elucidar o funcionamento das Generics

Um muito obrigado!

A todos que leram até, meus mais sinceros agradecimentos! Espero que tenha gostado, sinta-se livre para me acompnhar nas minhas redes

Referências

Ententendo o useEffect

Igor Oliveira — Wed, 29 Jun 2022 20:59:05 +0000

Entendendo o useEffect

Esse artigo tem como intuito, esclarecer o uso do Hook useEffect que foi introduzido no React 16.8. Este hook foi um dos quais tive mais dificuldades para entender e resolvi compilar o que aprendi nesse artigo

Primeiro, senta que lá vem teoria…

Antes de entramos no useEffect, vamos entender como funciona o ciclo de vida (lifecycle) de um componente.

No React temos basicamente três fases principais de ciclo de vida de um componente, são eles:

Mounting - é quando o elemento é colocado na DOM do navegador, ou seja, quando o elemento é renderizado em tela.
Updating - é quando um elemento tem alguma prop ou estado atualizado, isso faz com que o componente seja renderizado novamente em tela.
Unmounting - essa é a última parte do lifecycle de um componente, é nesse momento em que o elemento é retirado da DOM ou como é mais comum falar, o elemento é desmontado e deixa de existir em tela.

Dentro de cada fase de um lifecycle, o React antes da 16.8 possuia funções que ajudavam a manipular o elemento. Por exemplo, na fase de MOUNTING tinha o componentDidMount() que era chamado assim que o elemento entrava em tela, tinha o getDerivedStateFromProps() que era executado antes do elemento entrar em tela. Na fase de UPDATING havia o shouldComponentUpdate() que retornava true ou false (por padrão é sempre true) e especificava se o React deveria prosseguir com a atualização ou não e o componentDidUpdate() que executava algo assim que o componente atualizasse. Para finalizar, na parte de UNMOUNTING tinhamos o componentWillUnmount() que assim que o elemento saia da DOM ele era executado.

Olha quantas funções internas temos para lidar com o lifecycle dentro do React e isso foram apenas algumas funções, as que eram mais usadas no dia a dia do desenvolvedor. Em casos específicos era necessárias outras funções menos utilizadas.

A chegada dos Hooks

Com a chegada do React 16.8, fomos introduzidos ao Hooks e que coisa maravilhosa foi. Com eles foi removida uma camada de complexidade que o React possuia, para podemos comparar, abaixo tem um contador escrito com o conceito de Classes e outro com Hooks.

Olha a diferença de escrita de um componente com Classe para um escrito com Hook, temos um código muito menor e mais legível. Esse exemplo é de manipulação de estado com o useState. Mas a pergunta é: onde entra o useEffect?

Utilizando o useEffect

No começo desse artigo eu falei sobre como antes da versão do 16.8 era feito o lifecycle, mas e agora como é feito? É bem simples, vamos começar analisando a sintaxe do useEffect.

Podemos ver que o useEffect recebe uma função de callback e no final um array. A primeira coisa que me causou estranheza foi esse array no final, o que ele quer dizer?

Nós chamamos ele de array de dependências. No useEffect esse array pode não existir, pode existir e estar vazio e pode exister e conter um estado ou propriedade. Vamos entender melhor os casos:

useEffect sem o array de dependências - nesse caso o nosso useEffect vai ser chamado em cada ação que o usuário fizer em nossa aplicação, isso pode causar alguns loops indesejados na nossa aplicação.
Com o array de dependências vazio - com o array vazio, temos um comportamento semelhante ao componentDidMount() que falamos anteriormente. Nesse caso, assim que nosso elemento entrar em tela o useEffect vai ser chamado.
Com o array de dependências possuindo uma prop ou estado - podemos adicionar no array, uma propriedade que nosso componente recebe ou um estado interno e com isso, quando algum desses dados for atualizados nosso useEffect vai ser chamado.

Eu vou mostrar alguns exemplos de uso do useEffect:

Sem o array de dependências

Nesse exemplo, a cada ação do usuário na tela o useEffect irá lançar um console.log com a quantidade de vezes que o count foi chamado.

Com o array de dependências vazio

Melhorando ainda mais nosso exemplo, dessa vez vamos fazer uma chamada a API dentro do useEffect assim que nosso componente for montando em tela. Com isso teremos alguns dados em tela e como o array está vazio, o useEffect será chamado apenas uma vez.

Com o array de dependência contendo um estado

Melhorando o exemplos que criamos no exemplo anterior, vamos colocar um botão que incrementa um contador e toda vez que o contador mudar será feita uma nova requisição e o retorno será o usuário com o ID referente ao valor do contador

Limpando a bagunça

É comum quando um componente saia de tela, nós precisarmos limpar as coisas que foram feitas por ele. Antes da versão 16.6 do React nós utilizamos o componentWillUnmount(). Porém agora com o useEffect ficou muito mais simples, basta no final retornamos uma função e assim que o componente sair de tela a função será chamada. Vamos ao exemplo:

É comum algumas funções do próprio JavaScript precisarem ser limpadas após alguma ação e quando isso for necessário o próprio React irá nos avisar, como por exemplo quando usamos a função addEventListener() ****, depois dela ser executada é necessário fazermos a limpeza do evento com o removeEventListener(). Antes do hooks a função a ser usada seria a componentWillUnmount() e agora com os hooks basta retornarmos uma função no final do nosso useEffect que resolvemos esse problema.

Um muito obrigado!

A todos que leram até, meus mais sinceros agradecimentos! Espero que tenha gostado, sinta-se livre para me acompnhar nas minhas redes

Referência

ASDF: O gerenciador de versões universal!

Igor Oliveira — Wed, 12 Jan 2022 16:51:34 +0000

Hoje em dia em bem comun cada linguagem de programação ter seu próprio gerenciador de versão, como por exemplo o Node tem o NVM e o Ruby tem o RVM. Mas agora imagine que para cada linguagem que você use, você tenha que ter um gerenciador de versões diferentes e imagine o pior, e se tal linguagem não tiver um gerenciado de versões? Para isso foi criado o ASDF, ele permite que através de um único programa de CLI nós possamos instalar e gerenciar múltiplas versões de diferente linguagens.

Instalação

Vamos começar com o processo de instalação do ASDF, isso é bem simples. Basta entrar no seu terminal e digitar os seguintes comandos:

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.9.0

Hoje o programa se encontra na versão 0.9.0 e ela que estamos instalando.

Logo em seguida vamos configurar o ASDF no arquivo de configuração do nosso terminal, podendo ser tanto o arquivo .bashrc ou .zshrc. No meu caso eu estou utilizando o ZSH, logo vou fazer a configuração no .zshrc. Para isso basta utilizar o seguinte comando no seu terminal:

echo ". $HOME/.asdf/asdf.sh" >> $HOME/.zshrc

Instalando e Gerenciando versões

Primeiro de tudo, no ASDF cada linguagem de programação é um plugin. Vou deixar AQUI uma lista com todos os plugins disponíveis.
Como exemplo para este artigo, vamos instalar o NodeJs utilizando o ASDF.
Primeiro de tudo, precisamos entrar na página do plugin. Nela vai conter todos os passos para a instalação. Mas no geral os passos são esse:

1° - Adicionar o plugin com asdf plugin add <NOME> <LINK DO REPO>
2° - Instalar o plugin com asdf install <NOME> <VERSÃO>

Vamos instalar o NodeJs para exemplificar melhor.

Primeiro vamos adicionar o plugin:

  asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git

Agora vamos instalar o plugin, para fazer a instalação da última versão de alguma linguagem, basta utilizar a tag latest. E para versões específicas basta utilizar o número da versão. Ex: 15.8.2

    asdf install nodejs latest

Pronto, temos a última versão no Node instalada na nossa máquina!

Outros Comandos

Vou deixar uma lista alguns comandos mais utilizados

asdf plugin add // Adicionar um Plugin
asdf install // Instalar uma linguagem
asdf plugin list all // Listar plugins instalados
asdf remove // Remover uma linguagem
asdf update // Atualizar uma linguagem