O & do Sass

Sass

O & do Sass

Michelly Oliveira   16:11:00

O & é um recurso extremamente útil no Sass (e Less). É usado para aninhar . Pode ser uma boa economia de tempo quando você sabe como usá-lo, ou um pouco de perda de tempo quando você está lutando e poderia ter escrito o mesmo código em CSS normal.

Vamos ver se podemos realmente entendê-lo.

Aninhamento básico

.parent {
  .child {}
}

Isso compila para:

.parent .child {}

Você pode aninhar o quanto quiser, mas é uma boa prática mantê-lo apenas um nível ou dois para evitar seletores excessivamente específicos (que são menos úteis e mais difíceis de substituir).

Adicionando outra classe

O & vem a calhar quando você está aninhando e quer criar um seletor mais específico, como um elemento que tem *ambas* duas classes, assim:

.some-class.another-class { }

Você pode fazer isso durante o aninhamento usando o &.

.some-class {
  &.another-class {}
}

O & sempre se refere ao seletor pai ao aninhar. Pense no & como sendo removido e substituído pelo seletor pai. Assim:

O momento “ah”!

Pegue este Sass:

.parent {
  .child {}
}

Na verdade, isso pode ser considerado uma abreviação para aninhar com o &:

.parent {
  & .child {}
}

Então, esses dois exemplos compilam para a mesma coisa:

.parent .child {}

O exemplo com o & não é nada diferente do exemplo sem o &. Aninhar sem o & é uma abreviação de aninhar com ele. Podemos pensar no & como um mecanismo que nos permite colocar o seletor pai onde precisarmos dele em nosso seletor filho. Permite-nos aninhar com alterações. Vejamos mais alguns exemplos.

Usando o & com pseudo classes

Você pode escrever pseudo classes em uma classe de maneira muito menos repetitiva com o &:

.button {
  &:visited { }
  &:hover { }
  &:active { }
}

Isso compila para:

.button:visited { }
.button:hover { }
.button:active { }

O & neste caso nos permite posicionar .button diretamente ao lado de pseudo classes sem repetição no código de autoria. Se deixarmos de fora o & deste exemplo, o aninhamento básico colocaria um espaço entre eles assim…

.button :hover

… o que não é o mesmo.

Usando o & com >, + e ~

Usar o & com o combinador filho > , o combinador irmão adjacente + e o combinador irmão geral ~ é muito fácil. No começo eu pensei que você tinha que usar o &, mas:

// Atualmente você não tem que fazer isso.
// Aqui, o e comercial é implícito.
.button {
  & > span { }
  & + span { }
  & ~ span { }
}

Deixar os &'s fora do seletor funciona aqui:

// Este compila do mesmo jeito que anterior
.button {
  > span { }
  + span { }
  ~ span { }
}

Ambos os exemplos compilam neste CSS:

.button > span { }
.button + span { }
.button ~ span { }

Qualificação com base no contexto

Seletores aninhados não precisam necessariamente começar com o e comercial. Você pode qualificar um seletor colocando o & à direita.

.button {
  body.page-about & { }
}

Estamos reposicionando o seletor pai exatamente onde precisamos. Isso é realmente útil para qualificar um seletor com base em um pai diferente. Isso irá compilar para:

body.page-about .button {}

Ou seja, selecione a classe button apenas quando filho de body com uma classe page-about.

Ajustando a definição de &

Pense no & como não apenas sendo substituído pelo seletor pai, mas como sendo substituído pelo seletor pai *compilado*.

Isso é importante ao aninhar mais de dois níveis de profundidade, onde mais de um nível tem um arquivo &. Estes próximos dois exemplos malucos levam esse ponto para casa.

Exemplo maluco, mas funcional #1

Não escreva seletores assim:

.parent {
  .child {
    & div & & > a {}
  }
}

Para cada um &, ele será substituído pelo seletor pai compilado. Portanto, toda vez que houver um &, inseriremos .parent .child. Aqui está o CSS compilado:

.parent .child div .parent .child .parent .child > a {}

Exemplo maluco, mas funcional #2

.parent {
  .child {
    .grand-child & {
      &.sibling { }
    }
  }
}

Para compilar mentalmente este CSS, comece na camada superior e vá descendo, destacando as camadas externas e substituindo o & pelo novo seletor pai compilado.

Aqui está compilado:

.grand-child .parent .child.sibling {}

O que & não é

Descobri que de vez em quando estava usando o & para algo que não era. O & não permite que você percorra seletivamente sua árvore de seletores aninhados para um determinado local e use apenas uma pequena parte do seletor pai compilado que você deseja usar. Eu queria fazer algo assim antes:

.grand-parent {
  .parent {
    &(1) .child {} // Tentando pegar `.parent`, não `.grand-parent .parent`
  }
}

Minha intenção era que o & só fosse substituído .parent na esperança de compilar para isso:

.parent .child {}

Mas isso não funciona.

O & é sempre o seletor pai totalmente compilado.

@at-root para o resgate

Vale a pena mencionar que @at-root permite que você saia de sua estrutura de aninhamento inteiramente para a “raiz” de sua árvore de aninhamento.

.grand-parent {
  .parent {
    @at-root .child {}
  }
}

Nós nos teletransportamos para fora da árvore de aninhamento para este CSS compilado:

.child {}

Isso é legal. De uma perspectiva organizacional, todo o código ainda está agrupado, o que pode ser observado como um benefício não reconhecido do aninhamento. @at-rootpo de ajudar a manter os níveis de especificidade baixos porque você não tem mais o seletor pai compilado para aumentar a especificidade. Ao mesmo tempo, mantendo seu código conceitualmente organizado com aninhamento:

.grand-parent {
  .parent {
    @at-root body.page-about .child {}
  }
}

CSS compilado:

body.page-about .child {}

Existem alguns outros casos de uso para o & que pode ser divertido.

Duplicando a especificidade

Às vezes você precisa derrubar a especificidade de uma biblioteca CSS de terceiros para se apropriar do estilo:

.parent.parent {}

É muito menos avassalador do que usar e ID, estilo inline ou !important e pode ter benefícios sobre a qualificação do seletor com um elemento pai arbitrário. O nível de especificidade não é aumentado com base no contexto de um seletor, mas apenas por si mesmo. Com o & você pode fazer a mesma coisa assim.

.parent {
  &#{&} { }
}

Os colchetes de interpolação #{ } são necessários, pois dois e comerciais se tocam são Sass inválidos.

Modificando o e comercial

Mesmo que você não possa ter dois E comercial tocando sem os colchetes de interpolação — como demonstramos anteriormente em nosso exemplo de pseudoclasse — você pode fazer com que outro seletor toque o e comercial. Tocar no e comercial funciona bem com classes modificadoras.

.btn {
  &-primary {}
  &-secondary {}
}

CSS compilado:

.btn-primary {}
.btn-secondary {}

Isso pode ser bastante útil se empregar uma metodologia de nomenclatura (ou seja, BEM) que usa classes combinadas de traço e sublinhado em vez de seletores combinados.

Conclusão

O e comercial combinado com aninhamento é um ótimo recurso. Uma vez que você saiba o que está fazendo, criar seu Sass pode se tornar mais fácil, rápido e menos propenso a erros.

Aqui estão alguns outros artigos especificamente sobre o e comercial, para seu prazer de referência:

• Referenciando seletores pai usando o caractere e comercial de
  Adam Stacoviak
• Sass Snippets: The Almighty Ampersand por Una Kravets
• The e comercial & a killer Sass recurso de Joel Oliveira

Fonte: https://css-tricks.com/the-sass-ampersand/

Tipos de Parâmetros em requisições REST

REST

Tipos de Parâmetros em requisições REST

Michelly Oliveira   15:27:00

Neste post vamos falar um pouco sobre os tipos de parâmetros usados nas requisições em API's REST e exemplos simples de uso.

O que são parâmetros de API?

Os parâmetros da API são as partes variáveis ​​de um recurso (rota). Eles determinam o tipo de ação que você deseja executar no recurso. Cada parâmetro tem um nome e tipo de valor. Sempre que quiser construir uma API REST , você deve decidir quais parâmetros devem estar presentes nos endpoints da sua API . Em termos simples, os parâmetros da API são opções que podem ser passadas com o terminal para influenciar a resposta.

Tipos de parâmetros da API REST

Existem quatro tipos diferentes de parâmetros que geralmente são documentados e utilizados na prática em uma API REST. São eles:

• Header Parameters - Ex.: sessionId: 258dsf5ad8d
• Query Parameters - Ex.: /users?role=admin
• Path Parameters - Ex.: /users/{id}
• Body Parameters - Ex.: {"name": "Josias", "email": "josias@mail.com"}

Header Parameters

Esses parâmetros são apresentados no cabeçalho da solicitação e geralmente estão relacionados à autorização, como tokens, controle de sessão e dados de cookies. Esse tipo de parâmetro aparece em qualquer método HTTP (GET, POST, PUT, DELETE).

authority: josiaspereira.com.br
method: GET
path: /o-que-e-rest-um-resumo-rapido/
scheme: https
referer: https://josiaspereira.com.br/

Query Parameters

Os parâmetros de consulta são o tipo de parâmetro mais comum. Eles aparecem no final do URL de solicitação após um ponto de interrogação ( ?), com name=value. Cada parâmetro desse tipo é separado por e comercial ( &). Os parâmetros de consulta podem ser obrigatórios e opcionais.

Além disso, eles não são únicos, no sentido de que podem ser usados ​​para especificar qualquer parâmetro várias vezes.

http://myapi/pets/findByStatus?status=available
http://myapi/notes?offset=100&limit=50

Path Parameters

Os parâmetros de caminho são partes variáveis ​​de um caminho de URL. Eles geralmente são usados ​​para apontar para um recurso específico dentro de uma coleção, como um usuário identificado por ID. Um URL pode ter vários parâmetros de caminho, cada um denotado por chaves { }.

//http://myapi/users/{id}
//http://myapi/cars/{carId}/drivers/{driverId}

http://myapi/users/584
http://myapi/cars/25/drivers/9

Body Parameters

Eles estão incluídos no corpo da solicitação e são usados ​​para enviar e receber dados por meio da API REST. Há quem diga que esse tipo não é um parâmetro, mas decidi colocá-lo nesta lista pois é muito utilizado nas requisições PUT, e POST.

{ "name":"Josias", "age":26, "car":null }

Concluindo

Neste post vimos como cada tipo de parâmetro utilizado em requisições à API's REST funcionam e como utilizar cada um deles. Embora pareça simples, é muito importante ter esses conceitos em mete na hora de criar sua API.

Fonte: https://josiaspereira.com.br/tipos-de-parametros-em-requisicoes-rest