DEV Community: Lucas Souza

SCSS como você nunca viu

Lucas Souza — Mon, 04 Jul 2022 16:00:01 +0000

Olá mundo, tudo bom com ocês ? Hoje quero falar um pouco sobre scss e algumas novidades que existem / viram.

Caso queria ver o funcionamento de todas as novas features e/ou modificar algumas coisas basta acessar meu repo scss-like-you-never-seen e seguir o passo-a-passo para visualizar. deixa uma starzinha também ❤️

Antes de tudo !important

Algumas das funcionalidades que vou mostrar não possuem suporte ainda em todos os navegadores, mas é possível testa-las habilitando as flags respectivas em seu navegador.

EX: chrome://flags

basta agora procurar a flag desejada, habilitar e reiniciar o navegador.

Para ter uma leitura mais agradável e ver cada uma das fetures aconselho a clonar o meu repo scss-like-you-never-seen e rodar ele localmente. Dentro de cada pasta do repo existe um README.md explicando a feature.

Eu posso utilizar essas features ?

A documentação do SASS recomenda utilizar o sass ou dart-sass como compilador do projeto e assim conseguindo usar todas essas features sem problema. Caso você esteja utilizando ruby-sass ou lib-sass por exemplo acredito que não será capaz, visto que está deprecated.

Sass module mode

A uns anos atrás foi lançado um feature no scss que é chamado de scss modules basicamente ela permite que o seu estilo funcione como um modulo da aplicação assim liberando alguns recursos interessantes.

Existem duas formas de se utilizar o sass module:

nome.module.scss ou _nome.scss

Nas duas formas você vai poder usufruir de todos os recursos do sass module.

As novidades que vieram foi justamente o @use que permite que você importe um arquivo de estilo dentro de outro, para ser utilizado naquele contexto.

@foward que permite que você importe um arquivo de estilo dentro de outro e que ele seja passado para frente na importação.

Porque o `@import` é um problema ?

Usando o @import no scss encontramos um problema, um arquivo que possui por exemplo margin: 5rem; no final pode ficar com margin: 10rem;, caso tenha alguma váriavel com o mesmo nome da qual alimenta aquela propriedade, visto que o @import na hora da compilação leva em consideração a ordem.

EXAMPLE:

@import "spacings"; // margin: 10rem;
@import "variables";// margin: 5rem;
@import "mixins";
@import "colors";


.container {
  margin: var(--margin); // essa margin vem do variables
}

Caso a gente altere a ordem de importação, na hora que ocorrer a compilação será alterado o valor.

@import "variables";// margin: 5rem;
@import "spacings"; // margin: 10rem;
@import "mixins";
@import "colors";


.container {
  margin: var(--margin); // essa margin vem do spacings
}

O sass compila de forma procedural, ou seja, o valor da propriedade vai ser alterado de acordo com a última variável encontrada.

O problema que o `@use` e `@foward` resolve

@foward

Ele é similar ao @import, você vai passar para frente oque estiver em um contexto, não haverá sobre escrita.

@use

É utilizado no contexto e recebe um namespace, então se o meu arquivo se chama util tudo que eu utilizar ali será necessário passar o util como prefixo.

EX:

@use "_util";

.container {
  margin: util.$margin;
}

Caso não queria usar o namespace, esteja em processo de migração ou deseja utilizar outro nome porque o atual é grande, basta utilizar as e colocar um alias.

@use "_util" as u; // o prefixo agora é `u`
@use "_animations" as *; // não será necessário passar o namespace

7-1 pattern scss

"One file to RULE them all.

One file to FIND them.

One file to BRING them all.

And in the sass way MERGE them".

Esse é o pattern mais utilizado para desfrutar do scss modules, ou seja, o scss modules é um modo de modularizar, cada arquivo é um componente, e cada componente é um modulo. A sua estrutura é a seguinte:
abstracts, vendors, base, layout, components, pages e themes

Existem vários patterns 4-1, 5-1 etc. Tudo vai depender da sua necessidade.

particularmente utilizo bastante esse para meus projetos:

styles/
|
|– base/
|   |– _reset.scss       # Reset/normalize
|   |– _color.scss       # Paleta de cores da aplicação
|   |– _typography.scss  # Typography rules
|   |– _index.scss       # File used to import all base
|
|– layout/
|   |– _navigation.scss   # Navigation
|   |– _grid.scss         # Grid system
|   |– _header.scss       # Header
|   |– _footer.scss       # Footer
|   |– _sidebar.scss      # Sidebar
|   |– _forms.scss        # Forms
|
|– pages/                # Base views -> HOME, ABOUT, CONTACT etc.
|   |– _home.scss        # Home specific styles
|   |– _contact.scss     # Contact specific styles
|
|– themes/
|   |– _theme.scss       # Default theme
|
|– abstract/
|   |– _variables.scss   # Sass Variables
|   |– _functions.scss   # Sass Functions
|   |– _mixins.scss      # Sass Mixins
|   |– _index.scss       # File used to import all abstracts
|
`– _index.scss           # Main Sass file

Container Queries

Para utilizar o @container é necessário definir um query para o componente, fazemos isso da seguinte forma:

.nosso-wrapper {
  container-name: wrapper;
  container-type: inline-size;
}

O que fizemos a cima foi definir o tipo do container e o nome dele.

Note que o @container tem o mesmo funcionamento do @media, entretanto oque diferencia os dois é o container vai ter o adicional de poder utilizar operadores lógicos para definir o tamanho do container.

Oque também diferencia o @container do @media é que ele ajusta o tamanho dos elementos baseado na classe pai e não pelo tamanho do viewport.

EX:

@container wrapper (inline > 50px) {
  .nossa-classe {
    display: grid;
    align-items: center;
    justify-content: center;
  }
}

Compatibilidade: Chrome(🚧Beta), Firefox(🚧Beta), Chromium(🚧Beta) & Safari(✅Suportado)

Extend Rule

O extend é um recurso em que você replica o mesmo estilo de uma classe em outra.

Mas qual a diferença entre o @mixin e o @extend?

O mixin vai gerar uma copia daquele estilo em outro componente na hora da compilação.
Já o extends gera uma referência para a classe original.

EXAMPLE:

/// Mixin input

@mixin placeHolder {
    display: -webkit-box;
    display: -ms-flexbox;
    display: -webkit-flex;
    display: flex;
}
.classe1 {
    @include placeholder;
}
.classe2 {
    @include placeholder;
}

/// Mixin output
.classe1 {
    display: -webkit-box;
    display: -ms-flexbox;
    display: -webkit-flex;
    display: flex;
}
.classe2 {
    display: -webkit-box;
    display: -ms-flexbox;
    display: -webkit-flex;
    display: flex;
}

/// Extend input
.placeHolder {
    display: -webkit-box;
    display: -ms-flexbox;
    display: -webkit-flex;
    display: flex;
}
.classe1 {
    @extend %placeHolder;
}
.classe2 {
    @extend %placeHolder;
}

/// Extend output
.classe1,
.classe2 {
    display: -webkit-box;
    display: -ms-flexbox;
    display: -webkit-flex;
    display: flex;
}

Apesar do @extend ser mais simples, ele é tão poderoso quanto @mixin. Mas isso pode causar alguns problemas.

Como a classe .placeHolder é copiada para duas classes, elas são independentes e não se comportam como se fossem uma única classe.
Dependendo do comportamento da classe, a classe pai pode não ser a classe original.

Quando usar ou não o `@extend`?

Mixin: Utilize para gerar seu código de modo dinâmico através de variáveis;
Extend: Utilize para elementos comuns mas que haverá pouca repetição;

Quando for necessário criar algum tipo de automatização utilize o @mixin, caso contrario utilize o @extend, ou até mesmo os dois juntos.

Compatibilidade: Chrome(✅Suportado), Firefox(✅Suportado), Chromium(✅Suportado) & Safari(✅Suportado)

Has Selector

É uma pseudo classe que permite ao usuário selecionar um elemento do DOM e manipular caso o mesmo exista. Ele não pode ser utilizado dentro de classes css, somente selecionando seletores para seletores.

section:has(div) {
  color: red;
}

<section>
    <h1>Has Selector</h1>
    <div>
      <p>Message</p>
    </div>
  </section>

Compatibilidade: Chrome(🚧Beta), Firefox(🚧Beta), Chromium(🚧Beta) & Safari(✅Suportado)

Layer Rule

Define uma camada de cascata para ser trabalhada, as regas farão parte daquele contexto, não do escopo global da view.

EXAMPLE:

@layer base, component;

@layer base {
  .button {
    background: #eee;
    border: 1px solid #ccc;
    border-radius: 3px;
    color: #333;
    padding: 10px;
    margin: 10px;
  }
}

@layer component {
  .button {
    &__title {
      font-size: 1.5rem;
      font-weight: bold;
    }
    &__icon {
      margin-right: 0.5rem;
    }
  }
}

A ordem de declaração de camadas é importante, pois a camada mais acima será a camada mais próxima do contexto, então caso você altere a ordem a prioridade do estilo também mudará.

A propriedade layer pode ser útil para resolver problemas de prioridade não sendo mais necessário usar o atributo important.

Compatibilidade: Chrome(✅Suportado), Firefox(✅Suportado), Chromium(✅Suportado) & Safari(✅Suportado)

Conclusão

Ufa!! Foram muitas coisas que conseguimos ver hoje. algumas ainda estão em estado de desenvolvimento e será necessário ativar flags do seu navegador para testar.

Caso queria ver o código funcional de cada funcionalidade apresentada aqui basta acessar o meu repo scss-like-you-never-seen deixa uma star!

Até a próxima.

Documentação a linha ténue entre usar ou não o clean code

Lucas Souza — Sat, 04 Jun 2022 10:06:26 +0000

Olá mundo, como cês tão ein ?

Hoje eu quero falar sobre um tema muito interessante que particularmente curto muito:

DOCUMENTAÇÃO

Vou tentar ser o mais breve possível e mesmo assim compartilhar oque penso e como faço algumas coisas. Deixa ai nos comentários a sua colaboração. falando se concorda os discorda, enfim, vamos conversar. Boa leitura!

Porque documentar algo ?

Sempre que que vou estudar algo novo ou até mesmo revisitar algumas coisas que já fiz a documentação ajuda muito! Porque quando se escreve um código e não documenta ele, todo o conhecimento que você adquiriu ali pode ser perdido e necessário reestudar novamente, convenhamos que ninguém gosta de fazer algo duas vezes.

Então acabei pegando o costume de documentar grande parte das coisas que faço, seja na faculdade ou no trabalho. Tenho minhas colinhas com coisas que acho extremamente importante e que não posso esquecer.

Além desse benéfico de manter o conhecimento palpável, a documentação faz exercitar o seu conhecimento sobre determinado assunto e também ajuda a melhorar o conhecimento de outros. Vamos supor que você está em um time e que lá existem diversos processos para serem feitos, o seu onboarding nessa nova empresa será muito difícil caso não possuam essa documentação para te auxiliar. Entender gitflow, regras de negócio, reuniões, etc.

A documentação vem com o objetivo de ajudar a compartilhar conhecimento entre pessoas!

Tipos de documentação

Depois de um grande tempo eu acabei percebendo que existem alguns padrões de documentações:

Documentação de código;
Documentação em código;
Documentação de estudos;

.... muito mais

Vou falar um pouco sobre esses três porque, são os que possuo mais contato diariamente.

Documentação de código

Essa é a mais famosa! Esse tipo de documentação é a que explica como e porque aquele método existe, como ele é utilizado, como ele funciona, etc (as famosas regras de negócio).

Um exemplo bem massa é um fluxo especifico do seu sistema ex: pagamento, cadastro de usuários, como é armazenado os dados, como o front trata esses dados etc.

Vamos supor que em uma empresa hipotética você está trabalhando em um sistema de cadastro, mas ocorre uma mudança e você foi realocado para a parte de pagamento. Sendo algo que você nunca teve contato antes e nem conhece os fluxos o que vai fazer ? Como vai entender onde pode alterar quando ocorra um problema do sistema ? Oque alimenta seu serviço ?

Essas são respostas que uma boa documentação deve ter.

Ela não vai servir somente nesses casos, quando uma migração de sistemas ou uma mudança no fluxo de dados ali, vai precisar recorrer a doc. Só assim você vai ter certeza do que está mexendo e que não vai zuar o seu sistema.

Documentação em código

Essa é bastante polémica. Muitos defendem e outros tem aversão a esse tipo de documentação.

"Um código bem escrito já é uma documentação"

É uma frase bem comum entre programadores, mas nem tudo é escrito em pedra.

Na minha perspectiva a documentação em código é algo super útil e que ajuda o dev que irá fazer manutenção no futuro entender o que está acontecendo. A questão é escrever um comentário com 10 palavras ou 20 linhas é interessante mas se for realmente necessário.

exemplo tirado do kernel linux

unsigned int trace_call_bpf(struct trace_event_call *call, void *ctx)
{
 unsigned int ret;

 cant_sleep();

 if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1)) {
  /*
   * since some bpf program is already running on this cpu,
   * don't call into another bpf program (same or different)
   * and don't send kprobe event into ring-buffer,
   * so return zero here
   */
  ret = 0;
  goto out;
 }

 /*
  * Instead of moving rcu_read_lock/rcu_dereference/rcu_read_unlock
  * to all call sites, we did a bpf_prog_array_valid() there to check
  * whether call->prog_array is empty or not, which is
  * a heuristic to speed up execution.
  *
  * If bpf_prog_array_valid() fetched prog_array was
  * non-NULL, we go into trace_call_bpf() and do the actual
  * proper rcu_dereference() under RCU lock.
  * If it turns out that prog_array is NULL then, we bail out.
  * For the opposite, if the bpf_prog_array_valid() fetched pointer
  * was NULL, you'll skip the prog_array with the risk of missing
  * out of events when it was updated in between this and the
  * rcu_dereference() which is accepted risk.
  */
 rcu_read_lock();
 ret = bpf_prog_run_array(rcu_dereference(call->prog_array),
     ctx, bpf_prog_run);
 rcu_read_unlock();

 out:
 __this_cpu_dec(bpf_prog_active);

 return ret;
}

Oque esse trecho de código do kernel linux faz ? A resposta está nele.

Entendemos que o clean code é necessário e que códigos limpos são documentações! Mas existem processos que precisam ser explicitados em código para que QUALQUER pessoal entenda aquilo. Um processo complexo que toca em diversas partes precisam ser explicitados em código isso é um fato!

Precisamos para de demonizar isso falando que irá "sujar o código" é um contexto sensível e que necessita explicação ? Documenta inline mesmo, todo iram agradecer.

Documentação de estudos

Para documentar algo que você esteja estudando é legal também. Normalmente quando estou desenvolvendo algo utilizo o notion para fazer essa documentação, ou crio um /docs no repo e dentro dele coloco .md respectivos a contextos que achei necessário documentar.

Dessa forma no futuro caso eu queria entender novamente oque é um PropType mas da minha forma, bastar ler minha doc resumida! Cada pessoa interpreta de uma maneira então é mais fácil explicar algo no seu linguajar ? Mais fácil explicar algo feito por você para você não ? HAHAHA

Conclusão

A documentação é um dos mais importantes recursos do desenvolvimento de software e isso é um fato! Precisamos compartilhar conhecimentos porque pessoas vem e vão e softwares ficam muito mais complexos e difíceis de entender.

Toda empresa e DEV deve pensar em escalar a sua documentação porque só assim uma tecnologia se mantém viva.

Meu primeiro contato com o FastAPI

Lucas Souza — Fri, 03 Jun 2022 16:00:48 +0000

Visitei o FastAPI e aprendi bastante sobre o framework.

Olá pessoal! Como estão ?

Ultimamente eu tenho estudado bastante sobre back-end e principalmente python por conta da faculdade. Meu TCC tem como uma de suas ferramentas o Vue e o FastAPI.

A principio eu iria faze-lo com Django(uma ferramenta também em python que curto muito) mas acabei encontrando esse framework e achei a sua proposta de ser algo simples, prático e escalável muito interessante. Então eu decidi fazer um projeto com ele para entender a ferramenta.

Esse pequeno artigo só irá comentar um pouco da minha primeira impressão com a ferramenta e nada mais.

No final do post vou deixar um link para o projetinho que fiz usando a ferramenta e o seu deploy no heroku.

Conhecendo um pouco sobre a ferramenta

O FastAPI é uma ferramenta que tem como objetivo facilitar a criação de APIs e entrega isso para o desenvolvedor. Ela é mantida pelo Tiangolo e é um framework de código aberto, dito isso você pode contribuir com o seu código e colaborar com o desenvolvimento caso curta a ideia!

Para criar uma simples rota você só precisará de 5 linhas de código:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def root():
    return {"message": "Hello World"}

Quando eu vi isso pela primeira vez minha mente explodiu. Eu não sabia que existia um framework que fosse tão simples e fácil de usar, além de que ele gera automaticamente uma documentação para a API com Swagger ou REDOC, incrível não ?

Uma coisa bem interessante da ferramenta é ser async, ou seja para tarefas que precisam do contato com o banco, ou até mesmo em sistemas de microservices você pode utilizar dessa feature, o que o torna bastante escalável.

De pouco em pouco algumas empresas tem adotado o uso da ferramenta pela curva de aprendizado ser bastante simples.

Por debaixo do capo

A ferramenta vem com um conjunto de dependências conhecidas por algumas pessoas que ajudam na sua construção.

Pydantic
Starlette
Uvicorn

Esse conjunto de ferramentas já te entregam uma grande performance e a possibilidade de criar Schemas com o pydantic.

Falando nele você pode criar um Schema para o seu modelo e então utilizar o pydantic para criar um endpoint para o seu modelo.

Como assim um enpoit para o modelo ?

O FastAPI utiliza da arquitetura MODELS, ROUTERS & SCHEMAS.

MODELS é responsável por criar a sua nova tabela no banco de dados;
ROUTERS é responsável por gerenciar os seus endpoints, podendo conter ou não um repository;
SCHEMAS são responsáveis por criar a estrutura de dados para os seus endpoints.

Para saber mais sobre esse tipo de arquitetura você pode visitar o Bigger Applications - Multiple Files (FastAPI DOCS)

Do meu ponto de vista esse tipo de arquitetura é muito interessante e é uma forma de seguir o padrão de projeto.

Conclusão

Não sou nenhum expert em construções de API muito menos em python. Mas utilizando essa ferramenta consegui criar um CRUD com autenticação e para mim foi muito interessante. Por conta disso resolvi utilizar esse framework com uma das minhas opções no meu TCC.

Durante os meus estudos criei essa API com deploy no Heroku, caso esteja curioso para entender mais sobre acesse as docs da API do projeto e olha o código!

Deixei alguns TODOs lá como conexão com o postgres e a adesão de testes unitários utilizando o pytest(algo que vou falar no futuro).

Curti bastante a ferramenta vou seguir estudando! Quando tiver mais domínio volto aqui para falar mais sobre ❤️🌹.

Vue.js e os princípios do SOLID

Lucas Souza — Fri, 29 Apr 2022 00:34:41 +0000

Como criar um front-end mais coeso com uma manutenção simples e saudável

Olá pessoal! No meu querido diário de hoje vou falar um pouco sobre Vue.js e como podemos usufruir do SOLID para ter uma aplicação concisa. Meu texto surgiu de estudos e muita coisa dele foi baseado em um Artigo fenomenal do Manu Ustenko chamado How to avoid SOLID principles violations in Vue. JS application.

Esse artigo é de 2019 e utilizava Vue2, então como estou estudando sobre Vue3 decidi trazer uma versão minha como forma de aprofundar mais meus conhecimentos em Vue e no SOLID. Além de todos os componentes possuirem testes unitários.

Os princípios que serão abordados aqui podem ser replicados em qualquer framework de front-end e/ou em qualquer linguagem então caso não queria utilizar o Vue ~~procure um médico~~ use um que seja de sua escolha.

O inicio da jornada

Para entendermos melhor todos os princípios que comportam o SOLID vamos criar um TodoApp. o código de start do projeto está nessa branch do meu repositório. Existem branchs do passo a passo e as mesmas estão nomeadas de acordo com os princípios do SOLID, então caso queira achar alguma basta procurar pelo nome.

Mas porque devemos saber SOLID ?

As praticas de utilização do SOLID são mais eficazes em arquiteturas no back-end e isso é um fato, mas, ainda sim podemos extrair muitas coisas benignas disso para criar interfaces mais concisas e com uma lógica simples porém eficaz.

No dia-a-dia de uma empresa esses princípios vão ser utilizados a todo momento. Você vai desenvolver diariamente componentes que receberam informações de outro componente que vem de outro local e assim sucessivamente. Com o final dessa leitura sua visão sobre um código será completamente diferente da que você tinha no começo.

Entendo os conceitos do SOLID, será mais simples entender o Clean Code, além de que criar códigos limpos e legíveis dão uma vida útil maior ao seu produto.

Dependências para rodar a aplicação

Node 16.13LTS
Yarn

Single Responsibility Principle (Principio da Responsabilidade Única)

Esse principio aborda que uma classe, função ou estrutura não deve ter mais de uma responsabilidade.

Em nosso caso o componente HomeView possui 3 responsabilidades:

Mostrar o Header da aplicação
Carregar os todos na tela
Fazer a conexão a API

Nós não queremos isso! Com o tempo esse componente iria crescer mais e mais e suas responsabilidades junto a isso.

Vamos imaginar um componente no mundo real, algo que fosse responsável por efetuar o pagamento de uma compra, mostrar todos os itens dessa compra etc... Não seria legal ter a configuração de stores, conexões com api e diversas outras regras de negócio no mesmo componente não é ? Além de ter um tempo de carregamento enorme, poderia chegar a 3000 linhas ou mais tornando impossível fazer uma manutenção ou criar algo novo. Com o tempo isso se escalaria e no futuro se tornar impossível criar ou remover algo.

Então resumidamente esse principio visa deixar responsabilidades separadas para contemplar um contexto maior.

Com tudo isso em mente vamos refatorar o nosso código! Primeiro vamos remover essa responsabilidade do Header da aplicação.

HomeHeader.vue

<template>
  <header class="header">
    <nav class="header__nav" />
    <div class="header__container">
      <h1>My Todo List</h1>
    </div>
  </header>
</template>

<script lang="ts">
import { defineComponent } from 'vue'

export default defineComponent({
  name: 'HomeHeader'
})
</script>

<style src="./HomeHeader.scss" lang="scss" scoped />

HomeHeader.scss

$space-24: 24px;

.header {
  width: 100%;

  &__nav {
    background: teal;
    width: 100%;
    height: 50px;
  }

  &__container {
    padding: $space-24;
  }
}

Aqui criamos o componente HomeHeader que será responsável por mostrar esse novo titulo da Home e se caso no futuro tiver outras funcionalidades que envolva esse contexto como botão de logout, toggle de darkmode, etc poderá ser armazenado aqui.

O próximo componente a ser criado será o TodoList

TodoList.vue

<template>
  <div class="todo-list__container">
    <div
      :key="todo.id"
      v-for="todo in todos"
      class="todo-list__tasks"
    >
      <span :class="{ 'todo-list__tasks-completed': todo.completed }">
        {{ todo.title }}
      </span>
    </div>
  </div>
</template>

<script lang="ts">
import { defineComponent } from 'vue'
import { ITodos } from '@/helpers/interfaces/ITodos'

export default defineComponent({
  name: 'TodoList',
  props: {
    todos: {
      type: Object as () => ITodos[],
      required: true
    }
  }
})
</script>

<style src="./TodoList.scss" lang="scss" scoped />

TodoList.scss

$task-color: #4169e1;
$task-completed-color: #2e8b57;

$space-24: 24px;
$home-box-shadow: 0 1px 3px rgba(0, 0, 0, 0.12), 0 1px 2px rgba(0, 0, 0, 0.24);
$hover-box-shadow:  0 14px 28px rgba(0, 0, 0, 0.25), 0 10px 10px rgba(0, 0, 0, 0.22);
$home-transition: all 0.3s cubic-bezier(0.25, 0.8, 0.25, 1);


.todo-list {
  display: flex;
  flex-wrap: wrap;
  justify-content: center;
  align-items: stretch;

  &__container {
    padding: $space-24;
  }

  &__tasks {
    width: 24%;
    padding: $space-24;
    margin: 0.5%;
    text-align: left;
    color: $task-color;
    box-shadow: $home-box-shadow;
    transition: $home-transition;

    &:hover {
      box-shadow: $hover-box-shadow;
    }

    &-completed {
      color: $task-completed-color;
      text-decoration: line-through;
    }
  }
}

Removemos a lógica de mostrar o todo da Home, será apenas necessário passar a prop na Home e os TODOS serão renderizados sem maiores problemas.

Por último vamos remover a lógica de fetch na API da Home, visto que não é necessário ela ter conhecimento disso e nem ser responsável por isso.

Api.ts

export default async (url: string) => {
  const baseUrl = 'https://jsonplaceholder.typicode.com/'

  const response = await fetch(`${baseUrl}${url}`)
  return await response.json()
}

Resultado final

HomeView.vue

<template>
  <div class="home">
    <HomeHeader />
    <main>
      <TodoList :todos="todos" />
    </main>
  </div>
</template>

<script lang="ts">
import { defineComponent } from 'vue'
import { ITodos } from '@/helpers/interfaces/ITodos'
import TodoList from '@/components/TodoList/TodoList.vue'
import HomeHeader from '@/components/HomeHeader/HomeHeader.vue'
import Api from '@/api/api'

export default defineComponent({
  name: 'HomeView',
  components: { HomeHeader, TodoList },
  async mounted() {
    this.todos = await this.addTodo()
  },
  data() {
    return {
      todos: [] as ITodos[]
    }
  },
  methods: {
    async addTodo(): Promise<ITodos[]> {
      const api = Api('todos')
      return await api
    }
  }
})
</script>

Ufaa! Essa é a nossa Home pós refatoramento! Dito isso é bem perceptível quanto código removemos da Home e respectivamente a quantidade de responsabilidades removidas.

Anteriormente o componente Home era responsável por:

Mostrar o Header.
Fazer conexão com a API para buscar os dados.
Mostrar todos os todos.

Agora ela somente renderizar esses componentes e mostrar o resultado, não mais estando lotada de lógicas que não lhe fazem sentido. Ficando assim bem separado e com fácil manutenibilidade.

Open Closed Principle (Princípio do "Aberto Fechado")

O OCP(Open Closed Principle) declara que Objetos e entidades devem ser abertas para extensão, mas fechadas para modificação.

Atualmente o nosso componente TodoList recebe uma prop chamada todo que é responsável por passar o nosso objeto e as informações do componente serão renderizadas baseadas nisso.

Dentro do TodoList, existe um v-for que é responsável por essa função de atribuir os elementos para o destino correto. Mas como o OCP prevê, essa é uma responsabilidade que não deve ser de um componente.

Perceba, se um componente é responsável por gerar novos elementos internos ele abdicará de ser extensível e retornaremos ao primeiro principio.

Oque o OCP quer dizer com aberto para estender, mas fechada para modificação ?

Que um componente pode "aumentar" de tamanho mas nunca ser modificado. Então o nosso TodoList poderá sempre gerar novas listas de tarefas mas nunca ser capaz de modificar essas mesmas listas.

E para fazer isso no vue é bastante simples, vamos utilizar os slots e as props. Os slots vão ser responsáveis por abrir um espaço em determinado componente para ser capaz de renderizar algo especifico. Podendo ser um novo componente que faz parte desse contexto.

Um pouco confuso ? Vamos ver no código!

Primeiro vamos remover a responsábilidade de gerar essa todo do componente e por em um novo, que será chamado de TodoCard.

TodoCard.vue

<template>
  <div class="todo-card__tasks">
    <span :class="{ 'todo-card__tasks-completed': todoCompleted }">
      {{ todoTitle }}
    </span>
  </div>
</template>

<script lang="ts">
import { defineComponent } from 'vue'

export default defineComponent({
  name: 'TodoCard',
  props: {
    todoCompleted: {
      type: Boolean,
      default: false
    },
    todoTitle: {
      type: String,
      default: ''
    }
  }
})
</script>

<style src="./TodoCard.scss" lang="scss" scoped />

TodoCard.scss

$task-color: #4169e1;
$task-completed-color: #2e8b57;

$space-24: 24px;
$home-box-shadow: 0 1px 3px rgba(0, 0, 0, 0.12), 0 1px 2px rgba(0, 0, 0, 0.24);
$hover-box-shadow:  0 14px 28px rgba(0, 0, 0, 0.25), 0 10px 10px rgba(0, 0, 0, 0.22);
$home-transition: all 0.3s cubic-bezier(0.25, 0.8, 0.25, 1);

.todo-card {
  &__tasks {
    width: 24%;
    padding: $space-24;
    margin: 0.5%;
    text-align: left;
    color: $task-color;
    box-shadow: $home-box-shadow;
    transition: $home-transition;

    &:hover {
      box-shadow: $hover-box-shadow;
    }

    &-completed {
      color: $task-completed-color;
      text-decoration: line-through;
    }
  }
}

Esse componente ficará com a responsabilidade de preencher as listas com conteúdo. Então vamos utilizar props para tirar vantagem da comunicação entre componentes, assim podendo pegar os conteúdos e passar entre componentes.

Após isso vamos adequar o nosso TodoList

TodoList.vue

<template>
  <div class="todo-list">
    <div class="todo-list__container">
      <slot></slot>
    </div>
  </div>
</template>

<script lang="ts">
import { defineComponent } from 'vue'

export default defineComponent({
  name: 'TodoList'
})
</script>

<style src="./TodoList.scss" lang="scss" scoped />

TodoList.scss

$space-24: 24px;

.todo-list {
  padding: $space-24;

  &__container {
    display: flex;
    flex-wrap: wrap;
    justify-content: center;
    align-items: stretch;
  }
}

Agora o nosso TodoList é totalmente expansível de acordo com a necessidade de existências de novos TodoCard.

Resultado final

HomeView.vue

<template>
  <div class="home">
    <HomeHeader />
    <main>
      <TodoList>
        <TodoCard
          v-for="todo in todos"
          :key="todo.id"
          :todoCompleted="todo.completed"
          :todoTitle="todo.title"
        />
      </TodoList>
    </main>
  </div>
</template>

<script lang="ts">
import { defineComponent } from 'vue'
import { ITodos } from '@/helpers/interfaces/ITodos'
import TodoList from '@/components/TodoList/TodoList.vue'
import TodoCard from '@/components/TodoCard/TodoCard.vue'
import HomeHeader from '@/components/HomeHeader/HomeHeader.vue'
import Api from '@/api/api'

export default defineComponent({
  name: 'HomeView',
  components: {
    HomeHeader,
    TodoList,
    TodoCard
  },
  async mounted() {
    this.todos = await this.addTodo()
  },
  data() {
    return {
      todos: [] as ITodos[]
    }
  },
  methods: {
    async addTodo(): Promise<ITodos[]> {
      const api = Api('todos')
      return await api
    }
  }
})
</script>

Agora ficou mais claro não ? O TodoList terá de aumentar de acordo com a necessidade de surgir mais TodoCard como foi dito anteriormente, ou seja, não será mais internamente ao TodoList, essa responsabilidade se torna do TodoCard e o TodoList transforma-se em um "wrapper". Que é um componente genérico ou uma classe "abstrata" responsável por renderizar os Todos.

Liskov Substitution Principle (Princípio da Substituição de Liskov)

LSP diz que subclasses devem ser substituidas pela base.

Esse é um principio muito especifico que na maioria das vezes será utilizado somente por chamadas a API. Normalmente o Principio da substituição é difundida em aplicações back-end, mas da para extrair algumas coisas aqui.

É bem perceptível que até aqui todos os princípios tem objetivos em comum que geram um resultado maior, nesse em especifico precisamos deixar explico ao nosso código que tudo que for dependente de outra classe deve ser de fácil substituição pela classe pai. Ou seja, se tivemos inúmeras chamadas a diversos endpoints a classe pai deverá ter o maior controle sob essas outras dependências.

Mas cuidado se você tentar criar muitos laços entre classes tem a chance de quebrar o principio do OCP.

Na nossa aplicação vamos adequar todas as chamadas a API que possuímos.

BaseApi.ts

export class BaseApi {
  protected baseUrl = 'https://jsonplaceholder.typicode.com/'
  async get(url: string) {}
}

AxiosApi

import axios from 'axios'
import { BaseApi } from '@/api/BaseApi'

export class AxiosApi extends BaseApi {
  constructor() {
    super()
  }
  async fetch(url: string) {
    const { data } = await axios.get(`${this.baseUrl}${url}`)
    return data
  }
}

FetchApi

import { BaseApi } from '@/api/BaseApi'

export class FetchApi extends BaseApi {
  constructor() {
    super()
  }
  async get(url: string) {
    const response = await fetch(`${this.baseUrl}${url}`)
    return await response.json()
  }
}

Resultado final

Nosso código agora é controlado pelo BaseApi, onde toda nova classe que precisar fazer algum tipo de procura na API será controlado por ele.

import { BaseApi } from '@/api/BaseApi'
import { FetchApi } from '@/api/FetchApi'
import { AxiosApi } from '@/api/AxiosApi'

export class Api extends BaseApi {
  private provider: any = new AxiosApi()
  async get(url: string): Promise<any> {
    return await this.provider.fetch(url)
  }
}

Interface Segregation Principle (Princípio da segregação de interfaces)

Um componente não deve ser forçado a implementar uma propriedade ou interface que ele não utiliza.

É notável que esse principio aborda a necessidade de que os componentes só devem ter propriedades que somente irão suprir as suas necessidades e nada além disso. Para ser mais explicito em relação a isso vamos criar um novo componente chamado TodoRow

TodoRow.scss

$task-color: #4169e1;
$task-completed-color: #2e8b57;

.todo-row {
  width: 100%;
  text-align: left;
  color: $task-color;

  &__completed {
    color: $task-completed-color;
    text-decoration: line-through;
  }
}

TodoRow.vue

<template>
  <div class="todo-row">
    <span>{{ todo.id }}</span>
    <span :class="{ 'todo-row__completed': todo.completed }">
      {{ todo.title }}
    </span>
  </div>
</template>
<script lang="ts">
import { defineComponent } from 'vue'
import { ITodos } from '@/helpers/interfaces/ITodos'

export default defineComponent({
  name: 'TodoRow',
  props: {
    todo: {
      type: Object as () => ITodos,
      required: true
    }
  }
})
</script>
<style src="./TodoRow.scss" lang="scss" scoped />

Aqui percebemos que o componente agora possui somente uma prop que vai ser responsável por passar todas as sub dependências necessárias para o componente e não mais 2 como é no TodoCard.

Resultado Final

Vindo para a HomeView vamos ver essa diferencia mais nítida.

HomeView.vue

<template>
  <div class="home">
    <HomeHeader />
    <main>
      <TodoList>
        <!-- <TodoCard
          v-for="todo in todos"
          :key="todo.id"
          :todoCompleted="todo.completed"
          :todoTitle="todo.title"
        /> -->
        <TodoRow v-for="todo in todos" :key="todo.id" :todo="todo" />
      </TodoList>
    </main>
  </div>
</template>

Para cada elemento que existe dentro do componente TodoCard é necessário passar a sua prop e também o valor, algo que não é necessário e pode ser resolvido facilmente com apenas uma prop que alimentará o componente.

Dependency Inversion Principle (Princípio da inversão de dependência)

As funcionalidades ou classes devem depender de abstrações não de implementações, ou seja, uma classe pai não deve depender do seu filho e sim de classes abstratas.

Mais uma vez um principio do solid que torna-se mais útil com conexões a API. Esse principio visa a decentralização de dependências de classes de alto nível dos seus filhos. Um filho não pode mudar uma classe pai, mas sim o pai.

No nosso caso vamos somente criar uma interface para o método get que possuímos na aplicação e implementas em todas as chamadas que possuímos.

export interface IApi {
  get(url: string): Promise<any>
}

Essa interface vai ser responsável por ter o nosso método get e nas demais classes que dependem disso vamos implementar esse método e ele não será mais repetivo.

Resultado Final

Api.ts

import { IApi } from '@/helpers/interfaces/IApi'
import { BaseApi } from '@/api/BaseApi'
import { FetchApi } from '@/api/FetchApi'
import { AxiosApi } from '@/api/AxiosApi'

export class Api extends BaseApi implements IApi {
  private provider: any = new AxiosApi()
  async get(url: string): Promise<any> {
    return await this.provider.fetch(url)
  }
}

BaseApi.ts

import { IApi } from '@/helpers/interfaces/IApi'

export class BaseApi implements IApi {
  protected baseUrl = 'https://jsonplaceholder.typicode.com/'
  async get(url: string) {}
}

FetchApi.ts

import { IApi } from '@/helpers/interfaces/IApi'
import { BaseApi } from '@/api/BaseApi'

export class FetchApi extends BaseApi implements IApi {
  constructor() {
    super()
  }
  async get(url: string) {
    const response = await fetch(`${this.baseUrl}${url}`)
    return await response.json()
  }
}

AxiosApi.ts

import axios from 'axios'
import { BaseApi } from '@/api/BaseApi'
import { IApi } from '@/helpers/interfaces/IApi'

export class AxiosApi extends BaseApi implements IApi {
  constructor() {
    super()
  }
  async fetch(url: string) {
    const { data } = await axios.get(`${this.baseUrl}${url}`)
    return data
  }
}

Considerações Finais

Ufaaaa! Quanto conteúdo não ? Com tudo isso na nossa mente vamos organizar todas essas ideias e resumir bem.

Entendemos durante a nossa jornada que os princípios do SOLID nós ajudaram a construir uma aplicação mais limpa, um código legível em que cada parte é responsável por sua funcionalidade e as informações compartilhadas entre eles devem mostrar somente para quem é o destinatário daquele conteúdo.

Entendemos que componentes devem ter uma única responsabilidade e nada mais que isso. Com essa visão quando você estiver criando códigos pensará mais em durabilidade e manutenibilidade daquilo, já que é mais fácil fazer manutenção em algo que tem um objetivo e nada mais que isso.

Vimos também que um componente deve ser aberto para se expandir porém nunca para ser alterado, que devem ser passadas apenas as propriedades que realmente vão ser utilizadas e nada a mais.

Tendo em vista isso tudo como você sairá daqui ? Espero que um dev melhor, por códigos mais limpos e legíveis.

Muito obrigado pelo seu tempo e boa sorte!

Um terminal funcional e de respeito

Lucas Souza — Mon, 25 Apr 2022 22:54:02 +0000

O que você vai encontrar aqui ?

Olá meu caros! Hoje venho trazer para vocês um tutorial rápido para quem curte personalizações em terminal ou um shell diferente. Nesse tutorial, vou ensinar apenas a instalar o zsh e o oh-my-zsh no linux e também falarei um pouco sobre ambos.

Em outro artigo explicarei sobre os plugins que utilizo bem como os meus scripts personalizados e em outro ensinarei como instalar algo similar no Windows utilizando o oh my posh.

Vamos lá deixar esse terminal bonitão, boa leitura!

Antes de começar...

Vou deixar o link para meus dois gists que possuem minha configuração tanto para Windows(utilizando o oh-my-posh para personalização) quanto para Linux que será o ponto do artigo de hoje.

Nesses gist's encontra-se detalhadamente minha configuração para cada ambiente e também os plugins que utilizo.

Oque é zsh e oh-my-zsh ?

Zsh

Bom o zsh é um shell personalizado, por padrão todos os sistemas operacionais vem com um shell. Linux com o bash, Mac o mesmo e o Windows com o powershell.

Se vem por padrão um, porque eu utilizaria um shell personalizado ?

Essa é uma pergunta excelente e com uma resposta simples. Depende do seu uso e qual tipo de usuário você é.

O seu shell vai ser útil para todas as suas tarefas, não existe diferença discrepante entre o default e um que você venha instalar como o zsh, fish etc. Um shell custom vai te possibilitar ter uma experiencia diferente e diversas utilidades para o dia a dia como:

Autocomplete
Syntax higlight
Scripts personalizados
etc...

oh-my-zsh

O oh-my-zsh vai ser uma ferramenta que possibilita a configuração e gerenciamento do seu zsh. Podendo auxiliar na configuração de novos plugins, temas e dependências.

Um shell personalizado é para mim ?

Tendo isso tudo em mente você deve se perguntar se vale a pena ou não migrar de shell. O lado negativo disso é que algumas empresas podem barrar o uso de shell personalizado ou qualquer tipo de modificação no sistema operacional, normalmente empresas grandes dão uma máquina para o funcionário para que ele possa trabalhar e desenvolver.

Caso você esteja pensando em fazer isso no seu computador de trabalho, primeiro converse com seu gestor. Eu recomendo que seja feito na sua máquina pessoal.

Agora vamos para a melhor parte!

Começando!

Antes de tudo vamos utilizar o linux como primeiro exemplo. Para instalar o zsh vamos adicioná-lo a nossa maquina.

sudo apt install zsh -y

Nesse comando estamos instalando o shell zsh e passando a flag -y que não pedirá para confirmar a instalação.

Após isso vamos instalar o Oh-My-Zsh que permitirá personalizar de forma mais fácil o nosso novo shell.

sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Quando você rodar o script de instalação do oh-my-zsh, vai aparecer uma tela perguntando se você quer adicionar o zsh como shell padrão, basta digitar y e será feito.

Com o zsh e o oh-my-zsh instalado, se você der um ls -la na sua home, vai encontrar os seguintes arquivos:

Aqui encontramos a pasta de instalação do oh-my-zsh e também o .zshrc que para nós no momento é o mais importante.

Vamos configurar o terminal!

Com o passo anterior concluído chegamos na parte mais legal, configurar o seu terminal. Para iniciar vamos digitar o seguinte comando no termnal

zsh

Isso vai possibilitar a incialização do shell no seu terminal, na finalização de todo o processo vai ser necessário reiniciar a sua máquina para ele ficar como padrão.

Então vamos inciar a configuração. Para isso é necessário abrir o arquivo .zshrc com o seu editor de texto, para usuários de base ubuntu vamos possuir o gedit.

gedit ~/.zshrc

Com o seu editor aberto você vai encontrar algo parecido com isso:

Aqui é onde vamos adicionar a partir de agora todas as nossas configurações, scripts, plugins etc.

Abaixo pode-se perceber onde ocorre a conexão entre o seu shell(zsh) e o nosso "gestor" desse shell o oh-my-zsh.

Alterando nosso tema!

O oh-my-zsh te proporciona milhares de temas para adicionar ao seu terminal, você pode visualizar todos clicando aqui.
No meu caso vou instalar um chamado Spaceship que é o meu tema favorito.

Para alterar o seu tema do shell basta escolher um e altera-lo aqui:

Basta remover o tema padrão que é o robbyrussell e adicionar o seu escolhido na wiki do Oh-My-Zsh(disponibilizado no começo desse tópico).

Nesse ponto você já terá um terminal com um novo shell e um tema personalizado, para finalizar 100% será necessário reiniciar a sua máquina e então o seu shell padrão será o zsh. Mas caso queria seguir com o mesmo tema que utilizo basta prosseguir com a leitura!

Instalando e configurando o Spaceship

Clone o repositório

git clone https://github.com/spaceship-prompt/spaceship-prompt.git "$ZSH_CUSTOM/themes/spaceship-prompt" --depth=1

Symlink spaceship.zsh-theme para seu diretório de temas personalizados do oh-my-zsh:

ln -s "$ZSH_CUSTOM/themes/spaceship-prompt/spaceship.zsh-theme" "$ZSH_CUSTOM/themes/spaceship.zsh-theme"

Coloque ZSH_THEME="spaceship" no seu .zshrc como foi explicado no tópico anterior.

Com ele instalado você vai possuir algo parecido com isso:

E tadaaaaaaa!! Está ai seu terminal completamente personalizado e agora podendo visualizar versão do node, pacote do projeto e muito mais. Para finalizar 100% será necessário reiniciar a sua máquina e então o seu shell padrão será o zsh.

Caso queira ter acesso a minha personalização do tema Spaceship basta acessar meu gist

Muito obrigado e até a próxima!

DEV Community: Lucas Souza

SCSS como você nunca viu

Antes de tudo !important

Eu posso utilizar essas features ?

Sass module mode

Porque o @import é um problema ?

O problema que o @use e @foward resolve

@foward

@use

7-1 pattern scss

Container Queries

Extend Rule

Quando usar ou não o @extend?

Has Selector

Layer Rule

Conclusão

Documentação a linha ténue entre usar ou não o clean code

Porque documentar algo ?

Tipos de documentação

Documentação de código

Documentação em código

Documentação de estudos

Conclusão

Meu primeiro contato com o FastAPI

Conhecendo um pouco sobre a ferramenta

Por debaixo do capo

Conclusão

Vue.js e os princípios do SOLID

O inicio da jornada

Mas porque devemos saber SOLID ?

Dependências para rodar a aplicação

Single Responsibility Principle (Principio da Responsabilidade Única)

Resultado final

Open Closed Principle (Princípio do "Aberto Fechado")

Resultado final

Liskov Substitution Principle (Princípio da Substituição de Liskov)

Resultado final

Interface Segregation Principle (Princípio da segregação de interfaces)

Resultado Final

Dependency Inversion Principle (Princípio da inversão de dependência)

Resultado Final

Considerações Finais

Um terminal funcional e de respeito

O que você vai encontrar aqui ?

Antes de começar...

Oque é zsh e oh-my-zsh ?

Zsh

oh-my-zsh

Um shell personalizado é para mim ?

Começando!

Vamos configurar o terminal!

Alterando nosso tema!

Instalando e configurando o Spaceship

Porque o `@import` é um problema ?

O problema que o `@use` e `@foward` resolve

Quando usar ou não o `@extend`?