Pare de se preocupar com nomes.
“Preciso aprender X, Y, Z” — isso pode ser mais simples do que você imagina 😉
Se você chegou até aqui, acredito que seja um desenvolvedor. Nesse caso, a expressão “preciso aprender X” deve lhe soar familiar. E não sei você, mas quando via termos como “test driven development”, “grid layout”, “relações polimórficas”, “alternate flow”, “interface segregation”, “framework X” e ad infinitum, ficava com a impressão de que se tratava de alguma ciência de foguetes demasiadamente complexa.. mas a realidade não é bem assim.
TL;DR
Nomes servem apenas para identificar as coisas. Quando ouvir falar de algo novo, não pense logo de cara que aquilo é complexo demais — ou, pior ainda, “difícil” de aprender. Apenas entenda o conceito daquilo (o que/como se propõe a fazer/resolver), daí tente discernir se aquilo se encaixa para seu(s) projeto(s). Em caso afirmativo, faça a coisa mais básica possível com tal tecnologia e vá incrementando aos poucos, conforme necessário dentro do projeto. 😉
Quer ver na prática como não há nada de outro mundo por trás de “nomes bonitos”? Então saca só que legal: vamos fazer o caminho contrário da coisa, falando primeiro o que é, para só depois nomeá-la. Peguei um par de técnicas que empregam diferentes conceitos para exemplificar o ponto, além de alguns adicionais que serão bem válidos para exemplificar o ponto:
1°) [HTML/JS] Submetendo um formulário sem “atualizar a página”
Já vi algumas vezes essa, especialmente para formulários de contato. Mais ou menos algo como “tenho aqui esse formulário, daí queria/preciso enviar ele sem sair da página e exibir uma mensagem de sucesso”. Vejamos como fica a implementação desse recurso da forma mais simples impossível (sem usar nenhuma lib/framework).
Dado o seguinte formulário (de contato mesmo):
Até então nada de mais, html básico do básico, certo? Agora para fazer com que ele não mude a página do navegador, basta colocar um return false no onsubmit:
<form type=”post” action=”/customer/account/registerPost” onsubmit=”return false”>Se clicar em “Enviar” agora, ele não irá fazer mais nada. Próximo passo: a função que vai enviar o form. A abordagem é bem simples, por ora retonarmos ela no onsubmit:
<form type=”post” action=”/customer/account/registerPost” onsubmit=”return submitForm()”>E na função por enquanto só colocamos o return false:
const submitForm = () => falseÓtimo, agora continua não mudando a página, e podemos fazer qualquer coisa com com o form antes do return!
Para enviar o form, vamos injetá-lo em nossa função, simplesmente adicionando um this como parâmetro:
<form type=”post” action=”/customer/account/registerPost” onsubmit=”return submitForm(this)”>E daí para enviá-lo de vez:
Feito! Agora você poderá usar isso para qualquer formulário, que ele fará o submit de forma assíncrona e exibirá uma mensagem com a resposta do backend.
Só mais um detalhe, pode ser que dependendo da página, você queira um comportamento específico/diferente, certo? Para isso basta adicionar uma variável com uma função como segundo parâmetro:
<form type=”post” action=”/customer/account/registerPost” onsubmit=”return submitForm(this, outraFuncao)”>E no script:
Com isso, você já consegue enviar qualquer formulário assincronamente, e opcionalmente ainda colocar um comportamento opcional pra cada um deles!
Só nessa brincadeira você já usou Ajax (enviou o form sem sair da página), a Fetch API (meio nativo do JS pra trabalhar com ajax), um Callback (aquela variável com uma função/closure executável), Dependency Injection (por “injetar” tudo o que a função necessitava como parâmetros, sem precisar invocar nada externo à ela ou usar document.getElementByFoo) e o Open-Closed Principle (por causa do callback, você não precisa alterar a função submitForm pra cada form do sistema, deixando ela “fechada” para alteração, mas “aberta” para ser estendida (através do callback, nesse caso)). A propósito, esses dois últimos itens são as letras ‘D’ e ‘O’ de SOLID, respectivamente. Simples assim!
2°) [CSS] Posicionando elementos de forma simples
Essencialmente, os layouts de páginas/apps são formados por “blocos”, certo? Usemos um fragmento de wireframe da home de um e-commerce fictício como base:
Legal, agora foquemos na implementação de algumas partes aparentemente mais “complexas”: a grade com os produtos, os cards de cada produto e o header.
A grade de produtos poderia ser algo como:
Resultado:
Com essas poucas linhas “mágicas” já construímos uma grade de produtos responsiva. E isso que você viu aí é nada mais nada menos que o famigerado Grid Layout em ação! Simples, não?
Agora para cada item dessa grade, teríamos algo como:
Resultado:
Esse é o Flexbox.
E, de quebra, notou os nomes das classes? Se assim como eu você fica inspecionando site alheio pra ver como as coisas funcionam, já deve ter visto essa forma de dar nomes por aí.. esse estilo de nomenclatura é nada mais nada menos que o BEM CSS!
Por fim, para o header poderíamos ter algo como:
Isso já é suficiente para construir o header! Agora, só pra ficar responsivo, redistribuir os itens em telas menores:
E o resultado:
Mais um exemplo de Grid Layout, dessa vez usando Grid Areas. Simples, não?
Claro, dá pra fazer outras coisas com isso também, tipo desenhos 8-bit.. Mas aí fica a seu critério..
Compilado em vídeo com mais exemplos práticos
Há uma palestra que não canso de rever, feita pelo há alguns anos no InterCon PHP 2014: “PHP para Adultos — Object Calisthenics e Clean Code”.
Basicamente, em poucos minutos ele cita pouco mais de meia dúzia de conceitos (alternate flow, early returns, object calisthenics, single responsibility principle, open-closed principle, Liskov substitution principle, interface segregation, dependency injection e por aí vai), de forma absurdamente simples, e isso — vai por mim — vai te fazer uma diferença ENORME, vale muito a pena dar uma conferida! 😉
Indo além do desenvolvimento de software
Teoricamente você pode usar esse conceito (de focar na coisa em si primeiramente, e só depois se preocupar com o termo que a define) para praticamente qualquer coisa que esteja querendo aprender, inclusive outros idiomas.
Ao invés de se preocupar com a tradução do termo, foque no significado, naquilo que o termo identifica — e não no termo em si. Mesmo no seu idioma nativo, existem palavras que você desconhece, certo? Daí o que você faz? Procura saber à que se refere, e amarra o objeto/ideia/conceito àquela palavra. Trate palavras e expressões estrangeiras da mesma forma!
Caso não tenha conseguido deixar a ideia clara, saca só esse vídeo (bem curto) justamente sobre essa questão:
Concluindo..
Ouviu falar de uma tecnologia nova? NÃO pense que é algo de outro mundo e/ou que você tem que aprender “tudo” sobre aquilo pra só depois começar a usar! Apenas tente isso:
- Entenda o que tal tecnologia se propõe a fazer pra saber se/onde usá-la em seu(s) projeto(s),
- faça um overview breve e superficial para saber o que mais tal tecnologia tem a lhe oferecer,
- daí faça a coisa mais básica e simplória possível naquilo
- e vá evoluindo conforme precisar!
