DEV Community: Iury Nogueira

Criando modal/popover sem JS e CSS em 1 min!

Iury Nogueira — Fri, 05 Jan 2024 14:10:13 +0000

Juro que não é clickbait, existe uma nova funcionalidade no HTML que ainda é desconhecida por muitos que é o atributo popover, vou te ensinar a fazer a magia passo a passo, tomemos de exemplo essa tela:

<main>
  <div>
    <h2 class="no-margin">Hey, It's Iury Nogueira.</h2>
    <h2 class="no-margin">Fullstack Developer</h2>
  </div>

  <p id="info">I've been working as a full stack <b>web developer</b> for 10 years</p>

  <button>More details</button>
</main>

e você quer que o texto no parágrafo com id="info" apareça em um modal quando for clicado no botão de More details, para isso você só precisa informar quem vai ficar no modal com o atributo popover:

<p id="info" popover>I've been working as a full stack <b>web developer</b> for 10 years</p>

ao fazer isso vai notar que ele sumiu da sua página, agora você só precisa "conecta-lo" a uma ação, para isso vamos usar o atributo popovertarget:

<button popovertarget="info">More details</button>

com isso ele vai abrir o parágrafo que tem o id "info", pronto! O resultado é esse:

se você clicar fora do conteúdo vai notar que ele fecha também assim como um modal. Espero ter contribuído com essa dica, se você acha que outra pessoa desconheça compartilha esse post com ela, vlw! :D

#TesteSemNeura Desmistificando Testes Unitários com Jest

Iury Nogueira — Mon, 11 Dec 2023 13:37:12 +0000

Bem-vindo de volta! No último artigo, conversamos sobre a importância dos testes e como eles podem ser um diferencial na nossa jornada como desenvolvedores. Hoje, daremos um passo além e mergulharemos em um aspecto mais prático e aplicado dos testes unitários, focando na ferramenta Jest. Se você ainda não leu o artigo anterior eu sugiro a leitura.

#TesteSemNeura - Testes unitários, como comecei e como posso te ajudar.

Iury Nogueira ・ Aug 25 '22

#test #beginners #productivity #career

O Jest é uma das ferramentas mais populares para testes em JavaScript, não apenas simplifica o processo, mas também torna a experiência de escrever testes agradável, você pode usa-lo para testar seus códigos frontend e backend. Está preparado para elevar suas habilidades de teste e deixar o medo de lado? Então, vamos lá!

Antes de começarmos você precisa configurar o jest no seu projeto, para isso é só chamar nosso velho amigo npm, execute o comando na raiz do seu projeto.

npm install --save-dev jest

ou execute com o Yarn:

yarn add --dev jest

Particularmente eu gosto sempre de adicionar um novo script ao meu package.json para executar os testes, dessa forma:

"scripts": {
  "test": "jest"
}

Agora é só executar npm run test ou yarn test.

Vamos pegar um caso bem didático para nosso primeiro teste, quero que você se atente principalmente a estrutura do teste, eu costumo escrever testes pensando sempre na seguinte ordem: O que meu teste tem que validar, preparação/processamento e o que eu espero que seja correto na saída do processamento. Vou deixar mais claro com o exemplo abaixo:

// primeiro.test.js

test('dois mais dois é igual a quatro', () => {
  expect(2 + 2).toBe(4);
});

para executar esse teste execute:

npm test

ou execute com o Yarn:

yarn test

você verá essa saída no terminal indicando que seu teste passou.

note que eu procuro validar que "dois mais dois é igual a quatro", e eu espero (expect) que o resultado do processamento dessa soma seja 4 (toBe(4)). Por enquanto vamos nos atentar nisso, na estrutura de teste, o que se deve testar e o que esperar de cada teste, esse conceito é muito importante.

Vamos supor que você tenha uma função que deve recebe um valor em real (nossa moeda) e converte esse valor para dólar considerando que o dólar custa 5 reais. Vamos lá!

// conversorRealParaDolar.test.js

// Função que converte um valor de reais para dólar
function converterRealParaDolar(valor) {
  const valorDolar = 0.2;

  const valorConvertido = valor * valorDolar;
  return Number(valorConvertido.toFixed(2));
}

test('100 reais deve ser 20 dólares', () => {
  expect(converterRealParaDolar(100)).toBe(20);
});

test('deve lançar um erro para valores negativos', () => {
  expect(() => converterRealParaDolar(-100)).toThrow(
   'O valor a ser convertido deve ser um número positivo.'
  );
});

Note que eu chamo nossa função que converte e retorna o valor em dólar, mais uma vez checo o resultado com o toBe(), também adicionei um caso que um bom QA testaria, um número negativo! Nesses casos utilizamos o toThrow para checar uma exception, sempre é importante cobrir todos os casos possíveis de entrada para sua função e mapear os casos no teste, você pode escrever mais de um caso de test para uma mesma funcionalidade. Agora execute os testes com o comando que já falei anteriormente, você verá o seguinte resultado:

O segundo caso de teste quebrou pois nossa função não lança um erro quando um número é negativo, "mas Iury, é claro que o teste vai quebrar, como tu tá testando uma coisa que não foi implementada?" Isso é o que a gente chama de TDD! Basicamente você implementa todos os casos de teste e o desafio é você ir tirando o "vermelho" dos seus testes quando for implementando a função, mas isso é assunto para outro artigo, vamos seguir somente com esse breve conceito, um "ifzinho" no nosso código resolverá esse problema.

// funcao atualizada
function converterRealParaDolar(valor) {
    const valorDolar = 0.2;

    // chique né?
    if (isNaN(valor) || valor <= 0) {
      throw new Error('O valor a ser convertido deve ser um número positivo.');
    }

    const valorConvertido = valor * valorDolar;
    return Number(valorConvertido.toFixed(2));
  }

execute os testes novamente e veja que nosso teste passou, não é satisfatório? :)

O expect possui vários matchers, o mais comum como já usamos aqui é o toBe, outro muito comum de se usar no dia a dia é o toHaveLength onde você pode checar o tamanho de um array ou de uma string como no exemplo abaixo (repare também no not :D):

expect([1, 2, 3]).toHaveLength(3);
expect('abc').toHaveLength(3);
expect('').not.toHaveLength(5);

para conferir todos os matchers sugiro que você consulte a doc

Outro aspecto fundamental nos testes unitários é a cobertura de código, no exemplo da função de conveterRealParaDoar ela está 100% coberta porque nossos testes passam por todas as linhas de código, caso o teste da exception fosse removido nós não teríamos todo nossa função validada, por isso é importante sempre manter essa cobertura alta para que tenhamos o número máximo de casos possíveis mapeados em nossos testes, isso vai te ajudar a não ter aquele medo que falamos no primeiro artigo e você vai se sentir mais a vontade para realizar mudanças no código, agora vamos configurar a coleta do coverage!

Abra o arquivo de configuração do Jest (normalmente jest.config.js ou no bloco jest em seu package.json).
Adicione essa configuração para habilitar a geração de cobertura:

// jest.config.js

module.exports = {
  collectCoverage: true,
  collectCoverageFrom: ['src/**/*.js'], // esse é o caminho dos seus testes,
  coverageReporters: ['json', 'lcov', 'text', 'html'], // eu gosto de adicionar o HTML porque ele cria uma página bonitinha com vários progress.
};

Só executar!

npm test --coverage

ou execute com o Yarn:

yarn test --coverage

Acredito que com isso nós temos nossa porta de entrada para os testes, aconselho praticar com suas funções diariamente, no próximo artigo eu vou abordar sobre TDD!

Agradeço por sua leitura até aqui e gostaria muito do seu feedback, estou comprometido para melhorar e fornecer um conteúdo útil para ajudar no desenvolvimento de vários outros devs por ai a fora. Obrigado!

#TesteSemNeura - Testes unitários, como comecei e como posso te ajudar.

Iury Nogueira — Thu, 25 Aug 2022 12:19:33 +0000

Eai pessoal, tudo certo? Hoje vou falar para vocês sobre um assunto que foi um divisor de águas na minha carreira e que pode ser na sua também, inclusive nas minhas entrevistas eu sempre pergunto o grau de familiaridade que o candidato tem com as ferramentas de teste.

Meu objetivo nesse post é fazer com que você saia daqui pelo mais 10% apaixonado(a) sobre testes ou caso você é aquela pessoa que diz "codar um teste é perca de tempo" ou "exige tempo para fazer bem feito com teste" eu quero que você saia daqui desmistificando isso de uma vez por all, ok? Falo isso porque eu pensava da mesma maneira "não tenho tempo para fazer teste", "é complexo e eu não consigo", "o time não dá abertura para fazer isso" e inúmeras outras coisas que eu pensava para justificar a minha negligência.

Mas vamos lá, esse é um dos primeiros posts que eu vou falar sobre testes então esse artigo tende a ser mais teórico e motivador (tipo auto ajuda mesmo kkk), para exemplificar bem vou compartilhar algumas experiências que já tive como dev e como lead.

Testes unitários

Já ouviu falar? Vou ser o mais breve possível, esse teste tem a intenção de testar pequenas unidades do seu sistema, exemplo no frontend: Um botão, exemplo no backend: Um função que separa livros por gênero.

Memorize esses exemplos porque nós vamos trabalhar neles daqui pra frente!

Por que testar?

Vou responder essa pergunta com duas situações e é provável que você vai pensar "mermão eu passei/passo por isso".

Situação 1: Você precisa alterar uma função que está em produção que é chamada em vários locais do código. Você não fica com medo de alterar algo nesse código?, até a equipe de QA sente um calafrio na espinha quando vê uma task dessa.

Situação 2: Criar uma função de um comportamento cheio de casos específicos. Essa daqui é a coisa mais chata que existe, você implementa, salva, testa manual e verifica se funcionou, agora que funcionou implementa um novo caso e quebrou o caso que já tinha testado, quem nunca né?

Essas situações são bastante corriqueiras! Quando você se deparar com situações do tipo, alguém com medo de subir uma nova build, ficar apreensivo em adicionar mais um if em uma função, desconfiar do seu próprio código pensando "nem eu sei como que isso ta funcionando mas funciona e é isso ai kkkk" você caiu na malha fina dos testes! Testes impactam o negócio diretamente nos prazos, decisões e bem estar da equipe, nesse meu tempo de indústria vital eu já vi algumas features serem cancelados ou terem seu prazo "esticado" porque o time não conhece o código atual e não sabe o que vai acontecer se for alterado, então tem que estudar o código atual para saber até onde vai quebrar caso sofra alguma alteração. Já pensou se tivesse um teste? Provavelmente não teríamos esse problema. Isso é um exemplo claro da situação 1 e 2 juntas, alterar um comportamento ou regra do software é algo comum em muitos projetos.

Como foi para mim

No começo foi complicado colocar na minha cabeça o porque de testar coisas óbvias, era tipo "isso é tão claro, porque eu preciso testar isso?". Lembra do exemplo do botão? Vamos exemplificar alguns casos de teste para ele.

Button

✓ Deve renderizar a label do botão

✓ Deve ser clicável

Óbvio não? Claro! Agora imagine duas novas tasks: "Adicionar um botão com label e ícone" e "Adicionar um botão somente com ícone". Você vai ter que alterar o comportamento desse botão adicionado alguns ifzinhos para exibir label, label e icone, e somente ícone. Te lembra a situação 2? Sempre que alterasse qualquer coisa nesses comportamentos teria que verificar manualmente se todos os outros casos estavam corretos, com os testes óbvios implementados você não precisaria retestar manualmente os casos antigos manualmente. A lição é por mais óbvio que o teste pareça sempre vai ter uma importância a médio prazo e até curto caso você tenha amigos de projeto que comentam algumas coisas no código e esquecem de descomentar e comitam. Eu já fui "salvo" diversas vezes por testes óbvios! ~~porque eu era esse amigo 😅~~

Outra coisa que eu pensava erroneamente também era sobre os prazos, "não dá tempo fazer", eu não fazia teste porque não dava tempo mas estava levando o dobro de tempo ou mais para implementar algo novo porque eu precisava testar manualmente a cada iteração nova no componente e o pior.. Ficava com medo de ter deixado passar alguma coisa, então faça o seguinte questionamento para você e sua equipe, Você não tem tempo para testar mas tem tempo para corrigir bugs em produção e tempo para fazer revisões de códigos antigos para entender o comportamento das funcionalidades? Acredito que sua equipe também pode pensar assim porque de fato pensa na entrega e caso tenha bugs você vai ter tempo para corrigir esses bugs, mas isso é certo para você?

Depois que eu comecei a implementar eu comecei a me questionar muito sobre "isso é realmente necessário?". Meu conselho é que você continue implementando os testes, eu garanto ~~não que eu seja alguém hahaha~~ que irão aparecer os casos "nossa ia quebrar se eu não tivesse o teste", "ainda bem que tem o teste para ficar verificando isso", "refatorei e estou de boa porque eu sei que o teste passou".

Tome uma decisão

Se você chegou até aqui e ainda pensa que teste é perca de tempo ou que não tem tempo para fazer eu sugiro que pare de ler e volte depois, pode ser que para você não faça sentido agora. Isso mesmo, volte quando você estiver vivenciado mais as situações acima, talvez você tenha passado pouco por elas ainda. Já vi pessoas do meu time saírem de "fazer isso é chato" ou "é perca de tempo" e alguns meses depois cair na real e ver que estavam errados. Então se você está disposto a continuar descobrindo mais sobre testes eu já fico muito feliz!

Próximos passos

Eu aprendi o porque testar, quero continuar aprendendo como testar e quero contribuir com as pessoas que passam por os desafios diariamente que citei acima, então resolvi fazer vários artigos para ajudar vocês a saírem da zona de conforto, ser um dev melhor e transformar o time que vocês trabalham, estou disposto a ajudar com os próximos tutoriais e conto com a ajuda de vocês para que a gente atinja mais pessoas e mais times por aí a entregar melhor e sem medo.

Criando um modal com conteúdo dinâmico - Angular

Iury Nogueira — Thu, 09 Jun 2022 12:40:59 +0000

Olá ~~eu sou o Goku~~, meu primeiro post aqui 🎉, talvez você já tenha passado por uma situação de criar um componente com conteúdo de outro, existem algumas maneiras de criar um componente de forma dinâmica, para exemplificar esse comportamento vou utilizar como exemplo a implementação de um modal que tem seu conteúdo (corpo) modificado através de outro componente, vamos para a prática:

Vamos começar implementando nosso componente de modal, onde teremos os botões de concluir, cancelar, título e corpo (dinâmico).

import {
  Component,
  ComponentFactoryResolver,
  EventEmitter,
  Input,
  OnDestroy,
  OnInit,
  Output,
  ViewChild,
  ViewContainerRef,
} from '@angular/core';
import { ComponentType } from '@angular/cdk/overlay';

@Component({
  selector: 'dynamic-modal',
  templateUrl: 'dynamic-modal.component.html',
  styleUrls: ['dynamic-modal.component.less'],
})
export class DynamicModalComponent implements OnInit, OnDestroy {
  constructor(private resolverFactory: ComponentFactoryResolver) {
  }

  @Input() title: string = '';
  @Input() body!: ComponentType<{}>;
  @Output() closeMeEvent = new EventEmitter();
  @Output() confirmEvent = new EventEmitter();

  @ViewChild('viewContainer', {read: ViewContainerRef, static: false}) viewContainer!: ViewContainerRef;

  ngOnInit(): void {
    console.log('Modal init');
  }

  closeMe() {
    this.closeMeEvent.emit();
  }
  confirm() {
    this.confirmEvent.emit();
  }

  ngOnDestroy(): void {
    console.log('Modal destroyed');
  }

  ngAfterViewInit() {
    const factory = this.resolverFactory.resolveComponentFactory(this.body as any);
    this.viewContainer.createComponent(factory);
  }
}

Nosso body será o componente informado via service que será renderizado por nossa factory como está implementado no ngAfterViewInit.

Adicione também o HTML do componente de modal. Você sabia que os componentes do angular são desse tipo? ComponentType.

<div
  style="
    width: 500px;
    height: auto;
    border: 1px solid black;
    background-color: white;
    border-radius: 15px;
    display: flex;
    justify-content: center;
    align-items: center;
    flex-direction: column;
  "
>
  <h1 class="title">{{ title }}</h1>
  <div #viewContainer></div>
  <div>
    <button (click)="closeMe()">Fechar</button>
    <button (click)="confirm()">Salvar</button>
  </div>
</div>

a div que contém #viewContainer será responsável por renderizar nosso conteúdo dinâmico. Para chamar o modal que acabamos de criar vamos precisar adicionar um serviço que será responsável por receber os parâmetros necessários para a construção do modal como título e conteúdo (body dinâmico). Segue abaixo a implementação do service.

import {
  ComponentFactoryResolver,
  ComponentRef,
  Injectable,
  ViewContainerRef,
} from '@angular/core';
import { Subject } from 'rxjs';
import { DynamicModalComponent } from './dynamic-modal.component';
import { ComponentType } from '@angular/cdk/overlay'; 

@Injectable({ providedIn: 'root' })
export class ModalService {
  private componentRef!: ComponentRef<DynamicModalComponent>;
  private componentSubscriber!: Subject<string>;
  constructor(private resolver: ComponentFactoryResolver) {}

  openModal(entry: ViewContainerRef, modalTitle: string, modalBody: ComponentType<{}>) {
    let factory = this.resolver.resolveComponentFactory(DynamicModalComponent);
    this.componentRef = entry.createComponent(factory);
    this.componentRef.instance.title = modalTitle;
    this.componentRef.instance.body = modalBody;
    this.componentRef.instance.closeMeEvent.subscribe(() => this.closeModal());
    this.componentRef.instance.confirmEvent.subscribe(() => this.confirm());
    this.componentSubscriber = new Subject<string>();
    return this.componentSubscriber.asObservable();
  }

  closeModal() {
    this.componentSubscriber.complete();
    this.componentRef.destroy();
  }

  confirm() {
    this.componentSubscriber.next('confirm');
    this.closeModal();
  }
}

esse serviço é responsável por informar os @Inputs do nosso DynamicModalComponent, note que informamos o conteúdo do modal na seguinte linha this.componentRef.instance.body = modalBody;, agora nós temos um serviço que cria nosso modal (DynamicModalComponent) com título e conteúdo dinâmicos, com isso só precisamos agora chamar nosso serviço e informar os conteúdos para ele, essa é a parte que nós vamos chamar no dia a dia para criar um modal. Na tela que você precisa chamar o modal adicione os seguintes códigos:

constructor(private modalService: ModalService) {}

@ViewChild('modal', { read: ViewContainerRef, static: true })
  entry!: ViewContainerRef;
  sub!: Subscription;

openModal() {
// MyComponent é o componente que será renderizado dentro do seu body
    this.sub = this.modalService
      .openModal(this.entry, 'Título do modal', MyComponent)
      .subscribe((v) => {
        // dispara quando é aberto o modal
      });
  }

no HTML precisamos adicionar o botão ~~obviamente~~ para chamar a função openModal e uma tag para nosso ViewChild localizar.

<button
  (click)="openModal()"
  data-testid="button-login"
>
 Abrir Modal
</button>

<div #modal></div>

e prontinho! Aconselho fortemente criar um module separado para adicionar seus modais contents e esse componente de modal com o serviço dentro do mesmo módulo. Crie também um modelo bacana de modal ~~não use esse layout maravilhoso do post para o projeto kkk~~ e defina como padrão para todo o seu sistema, caso um dia o modal venha a ser alterado você precisará alterar somente em um local (modal.component.html).

É isso pessoal, espero que eu tenha conseguido contribuir com o desenvolvimento de vocês, também tenho que aprender e me empenhar para escrever mais por aqui então qualquer feedback
vai ser muito construtivo, obrigado! 🍻