DEV Community: Andres dos Santos

Como colocar um projeto no Github.

Andres dos Santos — Mon, 02 Nov 2020 17:45:24 +0000

Eaí pessoal, vocês já sabem como colocar seu projeto no Github? Se não sabe não tem problema, vamos resolver isso juntos.

Você já tem uma conta?

Antes de tudo, você vai precisar ter uma conta no Github, para isso basta acessar aqui.

Vá em SignUp e crie seu perfil.

Agora, crie um repositório.

Um repositório é um pedacinho da nuvem do Github, é ele que vai guardar seu código e ele pode ser público public ou privado private.

Para criar um repositório vá até o ícone de + e clique em new repository.

Agora ele vai te pedir um nome e perguntar se é público ou privado.

Depois de criado ele vai te dar algumas instruções sobre como fazer o push para o Github, mas se você é novo no site confesso que vai ficar um pouco confuso, bom, pelo menos eu fiquei 🤔.

Vamos ao terminal

Beeleza, vou considerar que você já tenha um projeto pronto. Com isso, abra o seu terminal na página que está seu App e digite.

$ git init

Caso não tenha o git instalado verifique aqui.

Agora, se você estiver no VSCode seus arquivos vão ficar todos na cor verde e vai ter um ponto ao lado dele.

Aqui é sempre bom lembrar de usar o .gitignore na raíz do projeto, pois ele vai evitar que alguns arquivos seus vá para o Cloud do Github, então alguns arquivos de chave, senhas, ou o próprio node_modules que ocupa muito espaço e não é necessário.

//.gitignore
/node_modules

Feito isso, voltaremos ao terminal. Mas agora iremos adicionar os arquivos.

$ git add .

Aqui eu adicionei todos os arquivos inicializados no git, menos os do .gitignore é claro.

Depois de adicionado todos os arquivos, temos que comentar esse ponto na história do nosso projeto, isso tem o nome de commit, e para fazer isso é simples. Então.

$ git commit -m 'o comentário que eu quiser'

Lembrando que é importante fazer um bom comentário aqui para você saber o que foi alterado no dia-a-dia do projeto.

Agora, vamos mudar a branch principal, branch é a linha que seu projeto está seguindo, por padrão o Github usa a master, mas a Microsoft alterou a pouco tempo para main, não sei porque mas...escolha da Microsoft né 🤷‍♂️

Então...

$ git branch -M main

Estamos quase lá, lembra que você criou um repositório? Então, nele tem uma linha dizendo algo como git remote..., isso vai adicionar seu código ao repositório que você fez, de forma remota.

$ git remote add origin https://github.com/<seu-nome-no-github>/<nome-do-seu-repositório>.git

Uffaa...adicionado!

Mas ainda não acabamos

O último processo é bem legal, é só fazer o push do seu projeto, o push é para empurrar seu código para as nuvem do Github, então...

$ git push -u origin main

Lembrando que deve ser jogado para a ramificação principal do seu projeto. Nesse caso é a main.

Bom pessoal é isso, espero ter ajudado, principalmente a quem nunca criou um repositório no Github 😁. Vaaaaleu!

Opaa, espera um pouco, me segue lá: Andres

Introdução ao GraphQL.

Andres dos Santos — Sat, 31 Oct 2020 21:37:31 +0000

Introdução ao GraphQL

Vamos trabalhar todos os dados do nosso produto por aqui, vamos usar ele como base.
"GraphQL é uma linguagem de consulta de dados desenvolvida e usada pelo Facebook desde 2012."

Pensa na timeline do Facebook, ele precisava pegar nome, URL, foto, conteúdo da postagem, ou seja, todas as informações daquele post, sendo de comentários, aí dentro dos comentários precisava pegar as informações dos usuários de dentro daquele post também, ou seja, muitas e muitas informações, e isso só no quadrado um único post, consequentemente isso ficcava muito pesado e para quase todos os usuários demorava muito, além de ser muito custoso para o servidor ter que ficar batendo em várias rotas. Foi por isso que eles desenvolveram o GraphQL.

REST API

Client(celular | computador) - HTTP request -> Server
Client(celular | computador) <- JSON - Server

A cada rota nova a API era atualizada, ou seja, o fluxo era refeito.

Problemas na REST API

Dificuldades para evoluir a REST API - para criar novas coisas nós tinhamos que criar elas e deixar funcionando a que já estava lá, aí era dividido, a rota antiga se transformava em 'v1' e a nova em 'v2', por exemplo.
Entrega de dados nem sempre necessários, quando a requisição é feita ele envia um monte de coisas, caso seja grande o JSON.
Aumento no tamanho da requisição, as rotas eram altamente acopladas, ou seja para pegar apenas alguns dados dos usuários nós tinhamos que criar outra rota para aquele tipo de serviço.

GraphQL

Preparando um schema com todos os dados.

type User = {
  name: String;
  bio: String;
  avatarURL: String;
  createdAt: DateTime!;
  followers: FollowersConnection;
}

type FollowersConnection = {
  edges: [UserEdge];
  nodes: [User];
  totalCount: Int!;
}

Mas eu posso passar apenas os dados que eu quero.

  query {
    user(login: 'Andres doSantos') {
      name,
      location,
      followers {
        totalCount,
      }
    }
  }

Ou seja, de um schema enorme, eu pego apenas um pequeno pedaço. E dele eu recebo apenas isso:

{
  "data": {
    "user": {
      "name": "Andres doSantos",
      "location": "Rio de Janeiro",
      "followers": {
        "totalCount": 3957
      }
    }
  }
}

Temos também as mutations para criação dos dados.
subscriptions que é uma outra forma de assistir as mudanças dos dados.
E vários outros detalhes dos GraphQL.

vantagens

Permite uma constante evolução - é apenas uma rota, não é necessários 'v1', 'v2', ...
Entrega seomente dos dados requisitados(tamanho menor e mais rápido), ou seja, o servidor responde mais rápido e o cliente baixa mais rápido.
Rota úncia, dados altamente desacoplados, eu passo, na criação da rota, tudo o que eu quero e ele me trás tudo o que eu preciso.

No GraphQL a URL é: https://graphql.github.com/graphql/proxy, as informações que eu quero passar vem no payload, então se eu fizer uma query requisitando nome, o nome vem no payload.

GraphQL Clients

São responsáveis por criar camadas de abstração para realizar queries/mutations, sistemas de cache, validações e otimizações.

Fetching Client é o mais simples, faz a chamada, recebe os dados e é isso aí, mais nada. Simples assim!

Caching Clients são mais robustos, pegam os dados, transformam, colocam em camadas de caches e assim nós não temos que ficar batendo todas as vezes na API se agente tiver todos os valores ali, eles tem também máquinas de estado, então nós conseguimos ter uma espécie de Redux dentro dele.

Quais os clients mais conhecidos/utilizados?

FetchQL
vantagens

É bem leve
API simplificada
Escrito com ES2015 e modules.
Isomórfico, ou seja, funciona no Node.js e no browser.

desvantagens

Não possui sistema de cache.
Não possui tratamento de dados e validações.
Não tem contexto de estado.

GraphQL request
vantagens

Simples e leve
Baseado em promises, ou seja, trabalha com async/await.
Suporte ao TypeScript.
Isomórfico, ou seja, funciona no Node.js e no browser.

desvantagens

Não possui sistema de cache.
Não possui tratamento de dados e validações.
Não tem contexto de estado.

uRQL
vantagens

Bastante leve e focado em performance.
Altamente extensível, podemos acomplar mais coisas e deixar ele mais poderoso.
Junto com Exchanges possui caching.
Possui suporte offline.

desvantagens

Biblioteca bem nova (poucos materiais sobre).
Pouca adoção no mercado.

Realy Modern
vantagens

Focado em performance.
Pré-compila as queries do GraphQL em build time(evita que o usuário baixe o parser).
Possui sistema de caching/states.

desvantagens

Necessita de configurações a mais no tooling, seja no webpack, no diretório de build, nos vamos ter que configurar isso.
Curva de aprendizagem é maior devido a mais detalhes para o funcionamento.

Apollo Client
vantagens

Largamente usado no mercado.
Focado em performance.
API simplificado e com suporte aos hooks.
Muito material online.

desvantagens

Extremamente grande!!! Nós temos a necessidade de usar o parser.
Atualizações constantes com Breaking Changes.

Espero ter tirado suas dúvidas em torno de algumas bibliotecas mais famosas do GraphQL e de como ele funciona, sinceramente eu não tinha noção que ele era assim, cheguei a dizer que ele não fazia sentido nenhum, mas agora faz : ), vaaaleu!

Tipos de aplicações

Andres dos Santos — Sat, 31 Oct 2020 15:24:31 +0000

Tipos de Aplicação

Site estático(HTML, CSS, JS) - GatsbyJS, Hexo - Pode ser um markdown ou um HTML que ele vai gerar um site estático.
Client Side Rendering(Single Page Aplication(SPA)) - Create React App - Nós teremos um arquivo JS que é baixado no browser e ele sim vai pegar tudo do lado do client e vai renderizar os dados que vai ser renderizado na tela.
Server Side Rendering(SSR) - Next.js - Tudo é renderizado no lado do servidor, então o usuário faz uma chamada, aí ele renderiza tudo do lado do servidor e depois ele é entregue para o client.

Entendo cada um

static site generation
vantagens:

Uso quase nulo do servidor, tudo já foi renderizado antes pelo servidor, ou seja, ele não vai ter quase nenhum processo para ele rodar.
Pode ser servidor numa CDN, aí eu tenho um cache melhor, não preciso ficar buscando tudo toda hora.
Melhor performance entre todos.
Flexibilidade para usar qualquer servidor, como é HTML, CSS e JS, eles são suportados por qualquer servidor. desvantagens
Alto tempo de building, várias páginas demoram mais e mais para carregar.
Dificuldade para escalar grandes aplicações.
Se é necessário atualizar muito, não vai dar para fazer bem.

single page application

vantagens

Permite ricas interações nas páginas sem precisar recarregar, a partir do momento que é baixado o app.js não é preciso ficar dando reload, afinal, tudo vai ser feito no browser.
Site mais rápido depois do load inicial, depois de feito o carrgamento do app.js ele já carregou tudo que precisava.
Ótimo para aplicações web, muito bom para Spotify web, Twitter web, Facebook web, porque ele possui várias libs para trabalhar aqui no SPA.

desvantagens

O load inicial pode ser muito grande, se o arquivo JS for muito grande seu load inicial pode demorar muito.
Performance imprevisível, porque numa página pode ter um JS maior, em outra menor, o que deixa inconsistências na performance.
Dificuldade no SEO, todo site é crawleável pelo Google, por exemplo, ele precisa disso para dizer sobre o que seu site fala, só que como é necessário carregar o JS para fazer requisições e depois renderizar, você não tem um conteúdo direto ali, você tem apenas uma etapa com o esqueleto pronto e aí sim, você tem o conteúdo.
A maioria não é indexado.

server side rendering

vantagens

É ótimo em SEO, tudo é renderizado no lado do servidor, então quando o Google abre seu site ele já recebe tudo pronto e certinho ali, todo o conteúdo.
Meta tags com previews certos, então todos os dados de titles, images, vai estar tudo correto de acordo com aquela página em questão.
Melhor performance para o usuário, pode ser visto mais rápido. É tudo entregue pronto. Abriu viu!
Código compartilhado com o backend em Node, porque como é renderizado no SSR agente pode ter as coisas do backend com o frontend se comunicando.
Menor processamento no lado do usuário, tudo é renderizado e entregue pronto. A máquina do cliente vai necessitar de pouco uso da processamento.

desvantagens

TTFB(Time to first byte) maior, o servidor vai preparar todo o conteúdo para entregar, então como tudo fica nas mãos do servidor ele precisa fazer todos os processos.
HTML maior, como ele já entrega todo o HTML montado, ele vai ser maior.
Reload completo nas mudanças de rotas, ele precisa recarregar a cada rota passada.

O Next.js suporta todos: SSG, SPA e SSR!

Mas quando usar cada um?

SSG

Para um site simples, sem muitas interções com o usuário.
Se você for a única pessoa que publica conteúdo.
Se o conteúdo muda pouco.
Se não tiver muitas páginas.
Exemplos: Landing page | Blog | Portifólios

SPA

Quando não tem tanta necessidade de indexar informações no Google.
Quando o usuário faz muitas interações nas páginas e não quero refreshes.
Quando as informações são diferentes para cada usuários, a exemplo o Twitter web | Facebook web.

SSR

Quando tem a necessidade de um SPA, mas precisa de um loading mais rápido.
Quando o conteúdo muda frequentemente.
Quando trabalha com um número muito grande de páginas.
Quando precisar de uma boa indexações no Google.
Exemplos: E-Commerce | Sites de notícias

Espero que tenham entendido pessoal, qualquer dúvida, envie aí que eu estudo e te passo, vaaaleu!

Como usar generics no TypeScript?

Andres dos Santos — Sat, 31 Oct 2020 13:43:26 +0000

Generics

Quando estamos escrevendo um código, uma das coisas que precisamos nós atentar é a reutilização dele, assim eu consigo escrever menos e ter apenas um ponto de contato caso tenha algum bug. Mas para fazer isso nós temos que tornar esses métodos mais genéricos. Quando nós trabalhamos com uma linguagem tipada igual ao TS nós sabemos que é preciso definir os tipos das nossas entradas no início e com isso o que era pra ser mais genérico acaba não sendo. É por isso que existem os generics que é para nós termos uma maior flexibilidade mesmo na linguagem tipada.

Vamos começar fazendo uma alusão ao useState do React

Nós vamos ver que podemos usar numbers e string através do union do TS. Então podemos começar com string e terminar com number ou vice-versa.

function useState() { 
  let state: number | string;

  // Pega o estado atual
  function getState() {
    return state;
  }

  // Seta um novo estado
  function setState(newState: number | string) {
    state = newState;
  }

  return { getState, setState };
};

const newState = useState();

newState.setState(123);
console.log(newState.getState());

newState.setState('foo');
console.log(newState.getState());

Agora nós vamos bloquear a alteração de tipo depois de definido

Então, se eu defino que é uma string ele não pode alterar mais esse tipo. Quando agente cria uma função nós temos os () que é onde ficam os atributos da nossa função. Então, antes deles nós vamos usar os generics. Em geral para passar os tipos nós usamos certos símbolos, que são letras com significado semântico.

Vamos conferir a sintaxe:

function useState<S>() {
  let state: S;
}

Vemos que alteramos o let state: de number | string para S, mas o que ele significa?

Esse símbolo representa para sua função que ela agora pode trabalhar com alguma coisa do tipo S. Na nossa primeira função passada acima, com esse código alterado ela ainda não vai mostrar erro, pois nós não falamos de que tipo é esse S.

Como definimos um tipo para S?

Ela é feita diretamente no momento em que nós chamamos a função. Por padrão o tipo desses atributos são unknow, eles aceitam qualquer coisa, mas quando é passado para ele um tipo ele passa a ser só daquele tipo. E é isso que causa a flexibilidade do generics.

Lembrando que temos alguma letras padrões:

S - State
T - Type
K - Key
V - Value
E - Element

Feito alterações o código fica assim:

function useState<S>() { 
  let state: S;

  // Pega o estado atual
  function getState() {
    return state;
  }

  // Seta um novo estado
  function setState(newState: S) {
    state = newState;
  }

  return { getState, setState };
};

const newState = useState<string>(); // Atribuição de tipo para S.

newState.setState('123');
console.log(newState.getState());

newState.setState(123); // ERRO - Pois foi atribuído string ao unknow.
console.log(newState.getState());

newState.setState('123');
console.log(newState.getState());

Agora, seu eu passo que ele é um number, boolean, any, ele vai passar a ser todos.

Mas isso gera um problema para nós, nós podemos alterar isso a qualquer momento!!!

Para bloquear que ele seja o que nós passarmos para ele, nós temos que mudar isso:

function useState<S extends number | string>() { 
  let state: S;
}

Aíiii, quando eu passar o primeiro tipo para ele, é esse que ele vai usar para sempre,
então...

function useState<S extends number | string>() { 
  let state: S;

  // Pega o estado atual
  function getState() {
    return state;
  }

  // Seta um novo estado
  function setState(newState: S) {
    state = newState;
  }

  return { getState, setState };
};

const newState = useState<number>(); // Pronto, agora ele só aceita number

newState.setState(123);
console.log(newState.getState());

newState.setState('123'); // AQUI VAI DAR ERRO!
console.log(newState.getState());

newState.setState(123);
console.log(newState.getState());

FALADO
"Eu sou flexível, posso ser qualquer coisa, mas depois que eu ganho um tipo, eu não mudo mais".

Agora, vamos colocar um tipo como default.

É simples, é só fazer isso:

// number é default
function useState<S extends number = number| string>() {} 

// Não preciso passar nada na chamada da função.
const newState = useState();

Uso

Esses tipos são muitos usados com os hooks do React, mas podem ser usados com uma infinidade de coisas. Aleḿ disso, eles funcionam também com objetos maiores como: React.FC<Props, States>.

Conclusão

Bom, é isso galera, espero poder ter ajudado, confesso que não é simples de entender mas é praticando que se aprender, então, vaaaleu, deixa eu ir praticar.

Cascata no styled-components

Andres dos Santos — Tue, 06 Oct 2020 21:36:25 +0000

Faaala Dev's! Hoje eu vou passar para vocês um "truck" no styled-components que eu demorei para pegar, não é dificil. Sabe quando nós vamos usar o CSS? Ele é escrito assim:

.container {
   margin: 0;
   padding: 0;
   box-sizing: border-box;
}

.container form {
   max-width: 300px;
   border: 1px solid #cd35bf;
}

Viu só! Ele é escrito no formato de cascata .container form. Daí eu pensei "preciso fazer isso no styled-components", mas como? Galera, é muito fácil, a sintaxe é assim:

import styled from 'styled-components';

export const Container = styled.div`
   margin: 0;
   padding: 0;
   box-sizing: border-box;

   form {
     max-width: 300px;
     border: 1px solid #cd35bf;

     h1 {
       color: #cd35bf;
       font-family: 'Roboto', sans-serif;
     }
   }
`;

Viu só, basta encadear no formato de objeto, onde h1 está dentro de form que estão dentro de Container.

Bom dev's por hoje é isso, qualquer dúvida ou sugestão comentem que eu busco para vocês, vaaleu! 😎

Como criar um projeto React Native com TypeScript

Andres dos Santos — Mon, 05 Oct 2020 01:33:57 +0000

Faaaala Dev's, no meu primeiro post vou ensinar a vocês a como criar um projeto React Native usando o TypeScript, já sabemos que o TS é o "amigo inteligente" do JavaScript, por isso ele vai ser cada vez mais usado no mercado já que as tipagens são de extrema importância na segurança de resposta e na manutenção do código. Já imaginou se o seu código começa a ficar muito grande e daí, no meio do caminho aparece aquele indesejável undefined? Isso vai te frustar bastante 😅, mas não se preocupe nós vamos mudando aos poucos tudo para o TypeScript 😎.

Lembrando que não é para destruirmos o JavaScript de uma vez por todas, até porque ao final tudo é bundle, ou seja, JavaScript.

Vamos definir o diretório

Eu particularmente gosto de deixar meus projetos em documentos, então bora navegar até lá.

No terminal, garanta que você esteje na raíz do usuário padrão do sistema.

$ cd ~

Agora que você está no usuário, navegue até documentos, para isso vamos usar o cd que significa change directory.

$ cd Documents/

Beleza, vamos criar uma pasta para o nosso projeto, usaremos o mkdir que significa make directory.

$ mkdir app

⚠️Atenção aqui!⚠️

De acordo com as últimas recomendações do pessoal do React não é legal ter o React Native CLI instalada globalmente no sistema, então vamos removê-los.

** Desinstalar **

$ npm uninstall -g react-native-cli

  ou

$ yarn remove -g react-native-cli

Finalmente podemos usar a cli do React Native para criar um projeto usando TypeScript. Então bora lá ...

$ npx react-native init FirstAppWithReactNativeAndTS --template react-native-template-typescript

Beleza Dev's espero que vocês tenham gostado desse primeiro post, fico por aqui e até a próxima.