DEV Community: Leonardo Santos

[PT-BR] Padrão de Projeto: Data Transfer Object

Leonardo Santos — Mon, 28 Dec 2020 20:57:57 +0000

Sempre quando ouvia falar sobre padrão de projeto eu já imaginava alguma implementação ou arquitetura muito complexa para o que eu estava acostumado. Porém, nos últimos tempos, me dei conta que estava trabalhando com um padrão de projeto que facilitava muito a "conversa" entre os sistemas clientes e os sistemas servidores e gostaria de explicá-lo nesse artigo.

Espero que a compreensão de algo que, para mim, num geral, era super complexo seja mais simples para vocês.

Data Transfer Object

O Data Transfer Object (DTO), ou conhecido em alguns lugares apenas como Transfer Object (TO), é um padrão em que utilizamos classes que possuem informações que são formadas a partir de uma ou mais entidades (classes cujos atributos são mapeados para os campos de uma tabela em um banco de dados). Essas classes tem o objetivo de simplificar a maneira como um sistema deve conversar com outro em relação à algum processo.

DTO na prática

O exemplo que demonstrei a seguir leva em consideração um processo de guardar um novo registro Usuário na base de dados e a resposta que a nossa API irá retornar.

Nesse exemplo, estarei utilizando uma implementação em Java com Spring Boot.

Classes

Nossa classe UsuarioEntity (responsável por fazer o mapeamento da nossa classe e atributos com a tabela e campos da base de dados):

package com.leonardossev.dtoexemplo.model.entity;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name = "usuario")
public class UsuarioEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Long id;

    @Column(name = "nome")
    private String nome;

    @Column(name = "email", unique = true)
    private String email;

    @Column(name = "senha")
    private String senha;

    // Getters e Setters...

}

Nosso Repository (interface responsável por interagir com a base de dados):

package com.leonardossev.dtoexemplo.repository;

import com.leonardossev.dtoexemplo.model.entity.UsuarioEntity;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

@Repository
public interface UsuarioRepository extends JpaRepository<UsuarioEntity, Long> {
}

Nosso Service:

package com.leonardossev.dtoexemplo.service;

import com.leonardossev.dtoexemplo.model.entity.UsuarioEntity;
import com.leonardossev.dtoexemplo.repository.UsuarioRepository;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class UsuarioService {

    @Autowired
    private UsuarioRepository usuarioRepository;

    public UsuarioEntity salvarUsuario(UsuarioEntity usuario) {
        return this.usuarioRepository.save(usuario);
    }
}

Nosso Controller:

package com.leonardossev.dtoexemplo.controller;

import com.leonardossev.dtoexemplo.model.entity.UsuarioEntity;
import com.leonardossev.dtoexemplo.service.UsuarioService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping(path = "/usuario")
public class UsuarioController {

    @Autowired
    private UsuarioService usuarioService;

    @PostMapping
    public ResponseEntity<UsuarioEntity> salvarUsuario(final @RequestBody UsuarioEntity usuario) {
        return new ResponseEntity<UsuarioEntity>(this.usuarioService.salvarUsuario(usuario), HttpStatus.CREATED);
    }

}

Executando nossa aplicação

Para testar o endpoint responsável por guardar o registro na base, utilizarei o Insomnia.

Lembrando que, se não especificarmos nenhuma porta, ao executar a nossa aplicação, ela estará disponível na porta 8080.

Note que estamos recebendo exatamente as informações que salvamos na nossa base de dados. Mas em uma aplicação real provavelmente não gostaríamos de receber todos os dados dessa forma.

Por exemplo: não iríamos querer que a senha do nosso usuário (sem entrar no mérito de criptografia) estivesse exposta dessa forma.

Outro exemplo: se quiséssemos trazer informações relacionadas ao usuário que não estão exatamente na tabela de usuário.

No nosso caso, o uso de DTO pode nos ajudar a solucionar essa questão de forma a nos permitir a escolher quais dados nós queiramos disponibilizar quando salvarmos um novo usuário.

Vamos adicionar a seguinte classe ao nosso projeto:

package com.leonardossev.dtoexemplo.model.dto;

public class UsuarioDTO {

    private Long id;

    private String nome;

    private String email;

    public UsuarioDTO(Long id, String nome, String email) {
        this.id = id;
        this.nome = nome;
        this.email = email;
    }

    // Getters e setters...

}

Vamos também fazer os seguintes ajustes:

Implementar um método na classe UsuarioEntity que irá transformar as informações da classe UsuarioEntitypara informações da classe UsuarioDTO;
Fazer com que o nosso endpoint retorne um objeto da classe UsuarioDTO.

Implementando método para transformar informações

Na classe UsuarioEntity vamos criar o seguinte método:

    public UsuarioDTO obterUsuarioDTO() {
        return new UsuarioDTO(this.id, this.nome, this.email);
    }

Alterando retorno do endpoint de salvar usuário

No nosso service, iremos ajustar a implementação do método salvarUsuario(UsuarioEntity usuario) para que ele possa retornar um objeto da classe UsuarioDTO:

    public UsuarioDTO salvarUsuario(UsuarioEntity usuario) {
        var usuarioSalvo = this.usuarioRepository.save(usuario);

        return usuarioSalvo.obterUsuarioDTO();
    }

Além disso, é necessário que façamos ajustes no método do nosso controller:

@PostMapping
    public ResponseEntity<UsuarioDTO> salvarUsuario(final @RequestBody UsuarioEntity usuario) {
        return new ResponseEntity<UsuarioDTO>(this.usuarioService.salvarUsuario(usuario), HttpStatus.CREATED);
    }

Dessa forma, quando executamos a aplicação e tentamos salvar um novo usuário, recebemos as seguintes informações:

Perceba que não estamos recebendo a informação da senha do usuário.

Considerações finais

O repositório com o exemplo do artigo pode ser encontrado aqui.

Referências

https://www.baeldung.com/hibernate-identifiers
https://stackabuse.com/data-transfer-object-pattern-in-java-implementation-and-mapping/

Em caso de dúvidas, estou sempre aberto a sugestões, críticas e ideias! o/

[PT-BR] CRUD com NestJS e MongoDB

Leonardo Santos — Sun, 27 Sep 2020 13:19:50 +0000

Uma das tecnologias que curto bastante estudar em meu tempo livre é Node. E, recentemente eu comecei a estudar um dos frameworks para se trabalhar com Node: NestJS.

Por já ter trabalhado com alguns frameworks tanto no frontend quanto no backend, o Nest me lembrou bastante conceitos que usamos quando trabalhamos com Angular e Spring Boot, como por exemplo Módulos, Filtros e Decorators.

Por já ter estudado um pouco desse framework e gostado bastante, gostaria de explicar aqui como seria possível fazer uma API para um CRUD básico. Dessa forma, se você estiver querendo se familiarizar com a ferramenta ou como trabalhar com Node, você pode ter mais uma referência.

Em relação ao banco de dados, irei utilizar o MongoDB.

A referência que utilizarei para esse artigo será a documentação do Nest e a documentação do Mongoose.

Vamos lá!

Mão na massa

Pré requisitos

Para começarmos a instalar o Nest e desenvolvermos a nossa aplicação, é necessário que tenhamos o Node instalado na nossa máquina. Para instalá-lo, podemos acessar esse link.

Para o desenvolvimento desse artigo eu estou utilizando o Node na versão 12.18.4 LTS.

Instalando CLI

Primeiro, vamos instalar o CLI do NestJS na nossa máquina. Em algum terminal de linha de comando, execute o seguinte comando:



## No Linux ou Mac
$ sudo npm install -g @nestjs/cli

## No Windows
$ npm install -g @nestjs/cli

Criando projeto

Já com o CLI do Nest instalado na nossa máquina, temos que ir até o diretório que desejamos criar o projeto e executar o seguinte comando:



$ nest new <nome-do-projeto>

Substitua o <nome-do-projeto> para o nome que desejar.

O próprio CLI irá nos perguntar se nós desejamos instalar as dependências do nosso projeto com o NPM ou com Yarn. Fique a vontade para escolher qualquer um dos dois.

Executando o projeto

Após ter criado o projeto e entrado na pasta do projeto, via algum terminal de linha de comando, execute o seguinte comando para executar o projeto:



$ npm start

Se desejar executar o projeto em modo watch, execute o seguinte comando:



$ npm run start:dev

Configurando a conexão ao banco de dados

Fique à vontade para escolher como desejará criar o banco de dados: seja ele na nossa própria máquina ou em algum lugar remoto. A nossa aplicação precisará apenas da string de conexão ao banco de dados.

Instalando dependências para trabalhar com MongoDB

Para trabalharmos com MongoDB em um projeto com Nest, existem algumas bibliotecas obrigatórias que precisaremos instalar no nosso projeto:



## Para trabalharmos com MongoDB em um projeto Nest
$ npm install mongoose @nestjs/mongoose

## Para termos o suporte do Typescript ao trabalharmos com o Mongoose
$ npm install -D @types/mongoose

Configurando a string de conexão

Com as bibliotecas instaladas, precisaremos configurar nossa aplicação para que ela possa se conectar ao MongoDB. Faremos isso ao abrir o arquivo src/app.module.ts e incluirmos o módulo do Mongoose, definindo a nossa string de conexão do banco:



import { Module } from '@nestjs/commons';

// Importamos o módulo do Mongoose
import { MongooseModule } from '@nestjs/mongoose';

@Module({
  // Suponhamos aqui que a nossa string de conexão seja 'mongodb://localhost/nest'
  imports: [MongooseModule.forRoot('mongodb://localhost/nest')]
})

export class AppModule()

Dica

Se precisarmos salvar esse código em algum repositório público, como Github, Gitlab e outros, sugiro a utilização da biblioteca dotenv. Com ela, poderemos definir variáveis de ambiente para o nosso projeto e, por conta disso, poderemos salvar nossa string de conexão ao banco como uma variável de ambiente. Assim não precisaremos expor esse e algum outro dado sensível da nossa aplicação.

Ao fazer isso, teoricamente, deveremos ter acesso ao banco de dados através da nossa aplicação.

Tente executar a aplicação nesse momento. Se houver algum problema ao tentar se conectar ao banco, surgirá uma mensagem em vermelha no seu terminal (onde tivermos executado o comando para executar a aplicação) dizendo que não foi possível se conectar ao banco de dados:

Nosso Model

Para quem não trabalhou com o Mongoose ainda, entenda que, basicamente, tudo que ele trabalha é derivado de um Schema. Os Schemas que ele trabalha irão mapear as nossas classes para um formato de Coleção e de seus respectivos Documentos no MongoDB.

De uma forma geral, eu gosto de interpretar que os Schemas, no Mongoose, fazem analogia à forma que trabalhamos com as Models em outros ORMs tradicionais para banco de dados relacionais.

Utilizando do sugestivo tema do Nest e, também, para exemplificar melhor o entendimento da construção da nossa API, vamos trabalhar com Gato.

Antes de criarmos nosso Schema, vamos organizar o nosso contexto de API em um módulo. Ou seja, a API específica para Gato que iremos criar estará toda organizada em um módulo. E, para isso, vamos executar o seguinte comando no nosso terminal:



$ nest generate module gatos

Após a execução desse comando, repare que foi criado um subdiretório chamado gatos dentro do diretório src do nosso projeto. Dentro dele irá conter o arquivo gatos.module.ts. Repare também que o nosso GatoModule (nome do módulo que foi criado) já foi importado no nosso arquivo AppModule.

Criando o Schema Gato

Agora que já criamos o nosso módulo, vamos criar nosso Schema. Vamos gerar a nossa classe através do CLI do Nest - igual fizemos com o nosso GatoModule - e vamos transformá-la em um Schema.

Para criar a nossa classe Gato, vamos executar o seguinte comando:



$ nest generate class gatos/gato

Repare que arquivo gato.ts foi criado dentro do subdiretório gato e seu respectivo arquivo de teste também foi criado, o gato.spec.ts.

O conteúdo do arquivo gato.ts, no momento, é basicamente o export da classe. Para transformarmos ela em um Schema para que o Mongoose consiga mapeá-la no MongoDB, precisaremos fazer o seguinte: estender a classe Document do Mongoose. E, também, precisamos adicionar o Decorator @Schema() em cima da declação da nossa classe Gato.

As modificações deixarão o arquivo com o seguinte conteúdo:



import { Schema } from '@nestjs/mongoose';
import { Document } from 'mongoose';

@Schema()
export class Gato extends Document {}

Vamos adicionar algumas propriedades à nossa classe Gato, utilizando o Decorator @Prop() da biblioteca @nestjs/mongoose:



import { Prop, Schema, SchemaFactory } from '@nestjs/mongoose';
import { Document } from 'mongoose';

@Schema()
export class Gato extends Document {

  @Prop()
  nome: string;

  @Prop()
  idade: number;

  @Prop()
  raca: string;
}

O Decorator @Schema(), por si só, não irá criar de fato um Schema. O papel dele é apenas marcar a nossa classe como algo que poderá ser mapeado, no banco de dados, como uma Coleção. É válido dizer que da forma que definimos ele, sem passar nenhum parâmetro, ele irá mapear essa classe como uma Coleção e irá adicionar o s no final do nome da Coleção no banco de dados. Ou seja, ele irá entender que essa classe está relacionada à coleção Gatos no banco de dados.

Agora, para criarmos de fato o Schema baseado nessa classe e exportá-lo, precisamos adicionar a seguinte instrução no final do nosso arquivo gato.ts:



export const CatSchema = SchemaFactory.createForClass(Gato);

A classe SchemaFactory deve ser importada da biblioteca @nestjs/mongoose. Nosso arquivo final ficará da seguinte forma:



import { Prop, Schema, SchemaFactory } from '@nestjs/mongoose';
import { Document } from 'mongoose';

@Schema()
export class Gato extends Document {

  @Prop()
  nome: string;

  @Prop()
  idade: number;

  @Prop()
  raca: string;
}

export const GatoSchema = SchemaFactory.createForClass(Gato);

Registrando o Schema Gato

Agora que criamos a nossa classe e o nosso schema, precisamos registrá-los no nosso módulo Gato e no módulo do Mongoose. Dessa forma, o Mongoose entenderá que a nossa classe e o nosso schema estarão definidos nesse escopo somente.

Então, para fazermos esse registro, vamos definir o conteúdo do nosso GatoModule dessa forma:



import { Module } from '@nestjs/common';
import { MongooseModule } from '@nestjs/mongoose';
import { Gato, GatoSchema } from './gato';

@Module({
  imports: [
    MongooseModule.forFeature([
      {
        name: Gato.name,
        schema: GatoSchema
      }
    ])
  ],
  exports: [],
  controllers: [],
  providers: []
})
export class GatosModule {}

Se caso quisermos utilizar a nossa classe e schema em algum outro módulo, precisamos apenas adicionarmos o MongooseModule dentro do array exports e, no módulo que formos utilizar a classe e/ou o schema, adicionarmos o MongooseModule no array imports.

Criando o Service Gato

A classe responsável por "conversar" com o MongoDB através do Mongoose, será o nosso GatosService. Para criarmos esse Service, precisamos executar o seguinte comando:



$ nest generate service gatos

Ao executar esse comando, dois arquivos serão criados no subdiretório src/gatos: o gatos.service.ts e gatos.service.spec.ts. O comando também irá adicionar o GatosService como um provider no GatosModule.

Para o nosso CRUD, iremos definir os seguintes métodos e suas respectivas implementações:



import { Injectable } from '@nestjs/common';
import { InjectModel } from '@nestjs/mongoose';
import { Model } from 'mongoose';
import { Gato } from './gato';

@Injectable()
export class GatosService {
  constructor(
    @InjectModel(Gato.name) private gatoModel: Model<Gato>
  ) {}

  async listarTodos(): Promise<Gato[]> {
    return this.gatoModel.find().exec();
  }

  async criar(gato: Gato): Promise<Gato> {
    const gatoCriado = new this.gatoModel(gato);

    return gatoCriado.save();
  }

  async buscarPorId(id: string): Promise<Gato> {
    return this.gatoModel.findById(id).exec();
  }

  async atualizar(id: string, gato: Gato): Promise<Gato> {
    return this.gatoModel.findByIdAndUpdate(id, gato).exec();
  }

  async remover(id: string) {
    const gatoApagado = this.gatoModel.findOneAndDelete({ _id: id }).exec();

    return (await gatoApagado).remove();
  }
}

Sobre o construtor do Service

A biblioteca @nestjs/mongoose nos fornece um meio para que possamos trabalhar com determinado Documento através da injeção de dependências com o Decorator @InjectModel. Para esse Decorator, precisamos apenas passar o nome da classe que foi marcada com o Decorator @Schema().

Sobre os métodos de CRUD

As implementações dos métodos podem variar de acordo com os tratamentos que acreditamos que sejam necessários. Para fins de praticidade, eu os implementei da forma acima. Porém, para um CRUD mais elaborado, é válido que seja aplicado alguns tratamentos de segurança e prevenção de erros (por exemplo: verificar se o objeto existe no banco de dados antes de tentarmos alterá-lo).

Criando o Controller Gato

A classe responsável por receber as requisições HTTP para trabalhar com o nosso CRUD de Gato será o nosso GatosController. Para criarmos esse Service, precisamos executar o seguinte comando:



$ nest generate controller gatos

Ao executar esse comando, o arquivo gatos.controller.ts será criado no subdiretório src/gatos. O comando também irá adicionar o GatosController como um controller no GatosModule.

A implementação do nosso GatosController será a seguinte:



import { Body, Controller, Delete, Get, Param, Post, Put } from '@nestjs/common';

import { Gato } from './gato';

import { GatosService } from './gatos.service';

@Controller('gatos')

export class GatosController {

  constructor(

    private readonly gatosService: GatosService

  ) {}

@Get()

  async listarTodos(): Promise<Gato[]> {

    return this.gatosService.listarTodos();

  }

@Post()

  async criar(@Body() gato: Gato): Promise<Gato> {

    return this.gatosService.criar(gato);

  }

@Get(':id')

  async buscarPorId(@Param('id') id: string): Promise<Gato> {

    return this.gatosService.buscarPorId(id);

  }

@Put(':id')

  async atualizar(@Param('id') id: string, @Body() gatoAtualizado: Gato): Promise<Gato> {

    return this.gatosService.atualizar(id, gatoAtualizado);

  }

@Delete(':id')

  async remover(@Param('id') id: string): Promise<Gato> {

    return this.gatosService.remover(id);

  }

}

Sobre o construtor do Controller

Assim como no nosso GatosService, o construtor do GatosController utilizará da injeção de dependência para que possamos acessar os métodos do nosso GatosService.

Sobre os Decorators do Controller

O Nest nos provê diversos Decorators que devemos utilizar em nossos Controllers.

Primeiro, para que possamos marcar uma classe como Controller, precisamos adicionar o Decorator @Controller() em cima da declaração da classe. Como argumento opcional, podemos passar um prefixo de rota para que possamos agrupar as rotas dessa classe em um mesmo caminho. Ou seja, de acordo com a implementação acima, todas as rotas que implementarmos nessa classe terá o prefixo /gatos.

Também temos Decorators para os métodos HTTP das nossas rotas:

Para requisições com o método GET precisamos definir o Decorator @Get();
Para requisições com o método POST precisamos definir o Decorator @Post();
Para requisições com o método PUT precisamos definir o Decorator @Put();
Para requisições com o método DELETE precisamos definir o Decorator @Delete().

Cada um desses Decorators de métodos HTTP podem receber um parâmetro que definirão os parâmetros da rota. No nosso exemplo, definimos apenas o parâmetro :id em algumas das nossas rotas.

Quando definimos um parâmetro de rota, podemos ter acesso a ele através do Decorator @Param() como argumento de nosso método. Apenas precisamos passar o nome do parâmetro que queiramos ter acesso. No nosso exemplo, definimos o parâmetro :id.

Para as rotas que esperamos um conteúdo no corpo da nossa requisição, utilizamos o Decorator @Body() como argumento de nosso método. Dessa forma, teremos acesso ao objeto que estará contido no corpo da nossa requisição através do argumento relacionado ao Decorator @Body().

Acessando nossa aplicação

Após configurarmos a conexão ao MongoDB, criarmos nossa Model e Schema, criarmos nosso Service e nosso Controller, já conseguiremos fazer o uso dessa aplicação.

Para acessar as rotas do nosso CRUD, inicie a aplicação e faça as requisições nas rotas que foram criadas no nosso Controller.

Dica

Ao iniciar a aplicação com as rotas criadas, no mesmo terminal que você executou o comando de execução da aplicação serão listadas as rotas que a aplicação já estará esperando por requisições:

Finalizando

A aplicação que foi criada nesse artigo pode ser encontrada nesse link. Em caso de dúvidas, estou sempre aberto a sugestões, críticas e ideias! o/

[PT-BR] Criando sua biblioteca com Angular 9+

Leonardo Santos — Wed, 02 Sep 2020 23:02:33 +0000

Olaar! Será que vocês já estiveram na seguinte situação que vou descrever abaixo? Se sim, espero que esse artigo possa te ajudar a fazer sua própria biblioteca e fazer com que você consiga evitar a reescrita de código. Se não, espero que o artigo ainda lhe acrescente algo :)

Disclaimer

Nesse artigo não demonstrarei como publicar a biblioteca em algum repositório. Também não desenvolverei módulos ou componentes na biblioteca.
Considero que você esteja utilizando o Angular 9 (ou alguma versão superior) e que você tenha conhecimento básico sobre o framework Angular.

Situação

Tenho mais de um projeto Angular que precisa utilizar um mesmo componente/uma mesma funcionalidade/um mesmo estilo.

Soluções

Para solucionar essa questão, uma opção seria reescrever o código necessário nos meus diferentes projetos. Uma alternativa bem prática mas que, em algum momento, se eu precisasse fazer alguma alteração nesse código comum entre os projetos, eu precisaria fazer em todos os projetos. 😥

Outra opção seria escrever esse mesmo código, que é necessário nos diferentes projetos, em um formato de biblioteca. Dessa forma, eu e outras pessoas poderíamos utilizar a mesma solução em vários projetos com apenas um código implementado.

Nesse artigo, eu pretendo explicar como que podemos resolver essa questão a partir da segunda solução mencionada acima.

Criando sua biblioteca Angular

Angular CLI

Para dar início à implementação da biblioteca, certifique-se que você possui CLI do Angular instalado na sua máquina. Você pode verificar se possui o CLI instalado ao executar o seguinte comando:

$ ng --version

Se caso você possuir o CLI do Angular instalado na sua máquina, você deverá ver informações como a versão do CLI do Angular e os pacotes do Angular que estão instalados na sua máquina com suas respectivas versões.

Se caso você não possuir o CLI ainda, basta executar o seguinte comando:

$ npm install -g @angular/cli

Caso esteja usando Linux ou Mac, você pode precisar do sudo:

$ sudo npm install -g @angular/cli

Criando a estrutura Angular

Agora é a hora em que, de fato, colocaremos a mão na massa! 👨‍💻👩‍💻
Execute o seguinte comando (explicarei logo abaixo sobre o comando, seu argumento e sua flag):

$ ng new <nome-da-estrutura> --create-application=false

A execução desse comando pode demorar alguns segundos/minutos (dependendo da velocidade da sua internet) para terminar de criar a estrutura.

ng new

O comando ng new é responsável por criar uma estrutura Angular. Com essa estrutura, podemos criar um ou mais projetos com o Angular. O argumento <nome-da-estrutura> definirá o nome do diretório que conterá a estrutura Angular e, também, definirá o nome do pacote que será gerado caso nós queiramos empacotar essa estrutura.

--create-application

Por padrão, quando executamos o comando ng new <nome-da-estrutura>, o CLI do Angular cria um diretório com uma estrutura que contém um projeto simples Angular. Porém, quando especificamos essa flag com o valor false, estamos dizendo ao CLI para criar somente a estrutura sem projeto algum.

Gerando biblioteca

Após ter criado a estrutura, entre no diretório que foi gerado pelo CLI e execute o seguinte comando:

$ ng generate library <nome-da-biblioteca>

Baseado na estrutura que criamos anteriormente, esse comando irá gerar uma pasta chamada projects que contém uma pasta com o mesmo nome que utilizamos como argumento do último comando (<nome-da-biblioteca>). Essa pasta contém todos os arquivos respectivos à nossa biblioteca!

Perceba também que no arquivo angular.json foi adicionado uma nova chave com as configurações relacionadas à sua biblioteca recém criada.

Buildando biblioteca

Para que consigamos compartilhar dessa biblioteca com outras aplicações, precisamos buildar essa biblioteca e transformá-la num arquivo que seja responsável pela instalação da biblioteca nas outras aplicações. Faremos isso executando, primeiramente o seguinte comando:

$ ng build <nome-da-biblioteca>

Para o nosso contexto, esse comando irá, basicamente, minificar e otimizar a nossa biblioteca. O comando gerará os arquivos otimizados da nossa biblioteca na pasta dist/<nome-da-biblioteca>.

Mesmo com esses arquivos, ainda precisamos de mais um passo para que possamos compartilhar a nossa biblioteca. Precisamos navegar até a pasta dist/<nome-da-biblioteca> e executar o seguinte comando:

$ npm pack

Esse comando irá empacotar todos os arquivos otimizados relacionados à nossa biblioteca e irá gerar um arquivo tarball. Esse arquivo terá o nome da nossa biblioteca junto com sua versão e, também, terá a extensão .tgz.

Pronto! Com esse arquivo, podemos facilmente utilizar a nossa biblioteca em outras aplicações.

Instalando biblioteca

Para instalar essa biblioteca, basta que tenhamos acesso a esse arquivo .tgz.

Para exemplificar, vamos navegar para fora dessa estrutura Angular que criamos e vamos executar o seguinte comando:

$ ng new <nome-da-aplicação>

Esse comando irá criar uma estrutura Angular com um projeto Angular já definido, como dito anteriormente.

Se caso quisermos utilizar a nossa biblioteca nesse projeto, basta navegarmos para dentro dessa nova estrutura que foi gerada e executarmos o seguinte comando:

$ npm install <caminho-para-o-arquivo-tarball>

Considerações finais

Com base em todos esses passos, você conseguirá criar sua própria biblioteca com Angular e também conseguirá instalá-la em outros projetos Angular.

Como dito no disclaimer, não contemplei como publicar a biblioteca em repositórios públicos/privados mas posso fazer isso em algum artigo futuro. :)

Para a escrita do artigo, utilizei a documentação do próprio Angular como apoio.

Finalizando, estou sempre aberto a sugestões, críticas e ideias! o/

Driblando separadores específicos dos SO's com Node.js

Leonardo Santos — Mon, 24 Feb 2020 06:43:04 +0000

Situação

Outro dia, no serviço, me encontrei em uma situação em que determinado projeto, desenvolvido em Node.js, estava sendo executado normalmente em minha máquina porém na máquina de outros colegas de trabalho não.

Problema

O problema relatado durante a execução do projeto era de que certos arquivos não estavam sendo encontrados em algumas configurações de importação.

Descoberta

Sugerimos então que o problema poderia se dar ao fato de estarmos utilizando diferentes sistemas operacionais. Enquanto que eu utilizava o Ubuntu 18.04, alguns outros colegas da equipe estavam utilizando Windows 10.

Resolução

Como dito anteriormente, o projeto havia sido desenvolvido em Node.js. E para a nossa alegria ele oferece um módulo para trabalharmos com arquivos e diretórios dentro de um sistema de arquivos: o módulo path.

O nosso projeto estava utilizando o método path.join() para "montar" os caminhos para as quais os nossos arquivos de importação estavam localizados. Porém, de acordo com a documentação do path.join():

The path.join() method joins all given path segments together using the platform-specific separator as a delimiter, then normalizes the resulting path.

Ou seja, ele utiliza o separador de diretórios do próprio sistema operacional. No caso, o Windows utiliza um separador diferente do Linux. Enquanto que o separador de diretórios no Windows é a \\ (barras invertidas, backslashes), o Linux utiliza a / (barra oblíqua).

Como solução, aproveitamos para utilizar um outro método que a API path nos fornece: o path.resolve().

Diferentemente do join(), o resolve() não faz o uso do separador específico do sistema operacional. Dessa forma, quando a normalização dos caminhos for realizada pelo Node.js, o mesmo caminho será percorrido tanto no Windows quanto no Linux ou macOS.

Utilizando path.join() e path.resolve()

A utilização de ambos os métodos é parecida:

Para o join():

path.join([params...])

Para o resolve():

path.resolve([params...])

Você passa para os métodos um array que "simulariam" o caminho para se chegar até determinado diretório/arquivo.
Exemplo:

Considerando que estamos no seguinte diretório /home/leo/app e queiramos navegar para dois diretórios anteriores (/home):

const path = require('path');

path.join(['..', '..')];

const path = require('path');

path.resolve(['..', '..')];

Ou, suponhamos que em /home/leo/app exista um diretório assets que possua outros diretórios dentro dele:

const path = require('path');

const profileImagePath = path.join(['assets', 'images', 'profile.png']);

const path = require('path');

const profileImagePath = path.resolve(['assets', 'images', 'profile.png']);

Você já se deparou com algum desafio envolvendo diferentes sistemas operacionais? Como resolveu?