@piluvitu

ㅤ

.env

• Para quem não sabe o seu sistema por padrão tem variáveis de ambiente, que servem para armazenar alguma informação e padronizar o acesso dela pela mesma.
  • É possível inserir váriáveis no próprio sistema sem precisar de nem uma abstração, mas ela não são inserções persistentes, por isso a fim de facilitar a definição dessas variáveis, existe o módulo do NPM .env, que foi criado a fim de facilitar isso.
• Para usa-lo tudo que é necessário fazer é criar um arquivo .env na raiz do projeto e inserir as variáveis com a seguinte sintaxe:
• O modelo é chave - valor, com a chave sendo por padrão MAIUSCULA

OPENIA_KEY = informação sensivel URL = localhost PORT = 3000

• Muito se é discutido em upar ou não o .env então devemos explicar o comportamento dele no sistema:
• .env.development - serve para um ambiente de desenvolvimento
• .env.example - serve como um arquivo de exemplo

• .env - é o arquivo padrão, que em teoria seria usado para inserir as variáveis de produção.

• Muitos dos provedores onde podemos subir nossas aplicações de maneira facilitada, disponibilizam uma parte para inserirmos as variáveis de ambiente que serão utilizadas na nossa aplicação e por ordem de importância essas variáveis inseridas antes do deploy, são as que vão realmente sobrepor as que ficam no .env.

ㅤ

GIT

• Pensando nisso o GitHub fez um artigo que sugere usar uma ferramenta do próprio git ou uma ferramenta open-source
  • Falando em git, descobri que tem como renomear arquivos usando o próprio git usando o comando git mv: git mv <nome do arquivo atual> <novo nome do arquivo>

ㅤ

Absolute PATH

• Eu nunca tinha parado para pensar que, quando queremos acessar algum arquivo que está fora da pasta atual: 1 - Navegamos para fora da pasta atual 2 - Entramos na pasta do arquivo 3 - Por fim referenciamos o mesmo.
• O nome disso é relative PATH e percebemos que priemeiro voltamos para depois seguir em frente, que em um projeto com muitos arquivos gera um PATH longo e nada didático
  • Já o absolute PATH é o caminho absoluto, que toma como padrão sempre sair da raiz do projeto e ir para o arquivo desejado, encurtando o PATH e deixando didático
• Fica a dúvida de como eles fazem para referenciar o diretório raiz do projeto ?
• Existem várias soluções no mercado, mas a microsoft desenvolveu os arquivos jsconfig.json e tsconfig.json que servem para indicar ao editor que ali é a raiz do projeto.

ㅤ

TypeScript

Por fim o typescript, meu primeiro contato sem auxilio de curso tem sido aqui na devhat, no projeto octopost, mal conheço e já considero pacas esse TS, estou fazendo minha introdução pelo curso da origamid.

• Estudei conceitos básicos de annotation, inferface e inferência.

// Annotation
const produt0: string = 'Livro'

let prec0: number = 856

• No TypeScript podemos tipar, e isso é interessante pois evitamos erros na hora de lidar com os dados

Interface

// Interface
const carr0: {
  marca: string
  portas: number
  motor: number
} = {
  marca: 'audi',
  portas: 2,
  motor: 3.0
}

carro.marca = 245
carro.portas = '2'
carro.motor = ['aspirado', 'alumínio']

Inferência

/* Mesmo sem declarar a tipagem, alguns tipos de variáveis o TS, 
já identifica a tipagem correta */

// Annotation
const produtos = 'Livro'

let preco = 856

preco = 'jajaja'

// Interface
const carro = {
  marca: 'audi',
  portas: 2,
  motor: 3.0
}

carro.marca = 245
carro.portas = '2'
carro.motor = ['aspirado', 'alumínio']

• Como pode-se ver no exemplo acima, podemos deixar de declarar a tipagem de alguns dados que o proprio TypeScript já reconhece.

function somar(a: number, b: number){
    return a + b;
}
soma(4, 10)
soma(4, "10")

• No exemplo acima é possivel ver um otimo motivo para tipar, pois saberemos o que é para chegar no parâmetro e o que será retornado

FunFact

• O vsCode tem intelisense de JS graças ao TS nativamente no editor, caso queira ter um pouco da experiência de usar TS no JS é só adicionar //@ts-check na primeira linha do seu arquivo JS e o editor vai passar a indicar alguns erros que o TS pegaria no seu código

@hxsggsz

ㅤ

Typescript

Essa semana eu estudei bastante Typescript pra tentar resolver um problema. Durante esse estudo eu descobri alguns Utilities Types criados pelo próprio time do Typescript pra facilitar a nossa vida difícil de bugs.

Como esses "Utilities Types" funcionam

Todos eles se beneficiam dos "Generics", algo muito útil na hora de tipagem e que é presente em diversas linguagens estaticamente tipadas.

Partial

O que ele faz? Ele transforma tudo em um objeto opcional. Olha esse exemplo:

interface User {
    id: string
    name: string
    role: "admin" | "user"
}

Agora se a gente taca essa interface no Partial assim:

type OptionalUser = Partial<User>

É como se a gente fizesse isso

interface User {
    id?: string
    name?: string
    role?: "admin" | "user"
}

Required

Existe o oposto do Partial que é o Required, e como o nome já diz, ele transforma todos os tipos que ele receber para necessário fornecer, até os que originalmente são opicionais

type OptionalUser = Partial<User>

type RequiredUser = Required<OptionalUser>

E agora o tipo RequiredUser fica assim

interface User {
    id: string
    name: string
    role: "admin" | "user"
}

Omit

Agora imagina que a gente quer omitir o nome da interface User sem alterar a interface original, essa é a função do Omit.

type UserWithouName = Omit<User, "name">

Pick

E tem o contrario também, imagina que a gente quer pegar apenas a propriedade nome da interface mas sem alterar a interface original, o Pick serve pra isso.

type UserName = Pick<User, "name">

Se você quiser pegar ou excluir mais de uma propriedade, basta usar o pipeline

type UserName = Pick<User, "id" | "name">

// ou 

type UserName = Omit<User, "id" | "name">

É possível combinar todos esses Utilities Types também

type UserNameOptional = Partial<Pick<User, "name">>

ReturnType

Agora imagina que a gente tem esse tipagem de função aqui:

type HandleSomething = () => string

E você precisa ter a tipagem do retorno dessa função, pra isso existe o ReturnType

type ReturnOfHandleSomething = ReturnType<HandleSomething>

Awaited

Imagina que você tem uma tipagem que é uma promise

type AwaitSomething = Promise<string>

E você quer a tipagem que essa promise vai retornar, pra isso serve o Awaited

type Result = Awaited<AwaitSomething>

Agora um caso um pouco mais real, você tipou uma função que retorna uma promise e você quer separar um type diferente o retorno dessa função, simples:

type UserNameOptional = () => Promise<string>;



type Result = Awaited<ReturnType<UserNameOptional>>;

Um exemplo com uma função real

async function awaitSomething() {
  await new Promise(() => setTimeout(() => "demorei mas cheguei", 1000));
}

// string
type Result = Awaited<ReturnType<typeof awaitSomething>>;