Include-media: Atualizar documentação para aliases de declaração

Você sempre pode usar variáveis:

$palm: "<=phone";
$lap: ">phone", "<=tablet";

<strong i="6">@include</strong> media( $palm ) { }
<strong i="7">@include</strong> media( $lap ) { }

Receio que isso não funcione @joseluis ( essência do Sassmeister ).

@hudochenkov Outras bibliotecas, como Breakpoint-sass , usam essa abordagem. Eu acho que não seria difícil adicionar essa funcionalidade para incluir mídia.

Vou pensar em uma possível sintaxe. Sinta-se à vontade para compartilhar suas idéias sobre isso também.

Opa, você está certo. O mixin não aceita uma lista como entrada.

@eduardoboucas Eu gostaria de propor que o

Parece bom para mim!

Obrigado, @joseluis , pela ideia e pela proposta de solicitação de pull :)

Eu acho que usar variáveis ​​como parâmetros vai contra a filosofia da mídia de inclusão. Minha ideia: crie uma nova variável $aliases semelhante a $media-expressions (ou use-a) e na função parse-expression analise-a, obtenha os parâmetros normais para media mixin e execute novamente parse-expression com estes parâmetros.

Olá @hudochenkov , estou curioso para saber por que você acha que isso vai contra a filosofia do projeto. Eu acredito que ele apóia o lema de usar consultas de mídia de uma maneira _simples, elegante e sustentável_.

Como a capacidade de usar variáveis ​​como argumentos é essencialmente inevitável, pois é herdada da própria linguagem Sass, a ideia é aumentar o suporte para essa linguagem expectativa de forma transparente. Isso permitiria formas mais criativas de chamar o mixin de mídia também.

Também gosto de como o código é lido:

$breakpoints: (phone: 320px, tablet: 768px, desktop: 1024px);

// e.g. aliases using variables
$lap: ">phone", "<=tablet";

<strong i="9">@include</strong> media( $lap ) { }


// e.g. aliases using map
$bp: (
  lap: (">phone", "<=tablet"),
  phonetop: (">phone", "<desktop")
);

<strong i="10">@include</strong> media( $bp(lap) );

Mas, de qualquer forma, ambas as ideias não são incompatíveis. Eu acredito fortemente que o mixin se beneficiaria imensamente por ser capaz de receber listas de parâmetros. Mas também poderia ser possível fornecer um mapa global adicional para "aliases" se a ideia tiver apoio suficiente.

@eduardoboucas o que você acha?

@joseluis , tentei sua adição e não está funcionando no caso para o qual criei este problema. E eu não explico este caso corretamente :)

Por exemplo, tenho site responsivo e em seu SCSS tenho muitos estilos para tablet e mobile.

.selector {
    color: black;

    <strong i="8">@include</strong> media(">phone", "<=tablet") {
        color: green;
    }

    <strong i="9">@include</strong> media("<=phone") {
        color: blue;
    }
}

Não quero repetir ">phone", "<=tablet" então posso criar aliases para isso:

$aliases: (
    "lap": (
        ">phone", 
        "<=tablet"
    ),
    "palm": "<=phone"
) !default;

e use estes aliases:

.selector {
    color: black;

    <strong i="17">@include</strong> media("lap") {
        color: green;
    }

    <strong i="18">@include</strong> media("palm") {
        color: blue;
    }
}

De repente, preciso adicionar a algumas regras parâmetros extras:

.selector2 {
    color: #bada55;

    <strong i="22">@include</strong> media("lap", "retina2x") {
        color: #b000b5;
    }
}

Atualmente, sua adição para suporte a variáveis ​​falha:

.selector2 {
    color: #bada55;

    <strong i="26">@include</strong> media($lap, "retina2x") {
        color: #b000b5;
    }
}

Mesmo quando você resolve este caso também, a sintaxe dos parâmetros para media mixin não era consistente: seu $lap, "retina2x" vs estilo de mídia de imagem hipotética "lap", "retina2x" .

Eu apoio totalmente a adição de variáveis ​​para parâmetros, mas também quero o suporte de inclusão de mídia “nativa” para aliases.

@hudochenkov eu entendo. E agora estou com você. Vejo como é útil ter um mapa global para aliases da maneira que você propõe (embora eu goste mais do nome $media-aliases ). Eu gostaria de ouvir a opinião de @eduardoboucas sobre isso.

Eu imagino que uma chave de alias deve ter precedência sobre $breakpoint key . Tentarei apresentar um novo PR que ofereça suporte a pseudônimos globais de uma forma sensata.

BTW, seu caso de teste funciona para mim usando a mixagem do PR anterior (sm gist) .

Desculpe pessoal, não estou ignorando vocês. Terei um bom tempo esta noite para me dedicar a isso e vou deixar você saber o que penso. Obrigado!

@joseluis sobre <strong i="6">@include</strong> media($lap, "retina2x") { } . Que pena, escrevi retina vez de retina2x no meu teste :) BTW, será ótimo se tais erros forem tratados por include-media e ignorados.

Obrigado @eduardoboucas ,

Acabei de terminar um exemplo de trabalho adicionando suporte para aliases ao mixin de mídia:

Meus comentários: Eu acredito que é mais lógico modificar o mixin de mídia em vez de modificar a função de expressão de análise. Esta é a maneira mais simples que vejo de fazer. Eu poderia ter criado uma função auxiliar para lidar com as listas, mas não acho que valha o esforço ainda.

@hudochenkov Sim. Também acredito que os erros de inclusão de mídia poderiam ser tratados melhor. Vamos ter isso em mente para outro PR.

Eu gosto da abordagem $media-aliases , embora esteja um pouco preocupado que a implementação eventualmente se torne muito complexa. Acho que em algum momento essa biblioteca não conseguirá agradar a todos. Mas se isso em particular for útil para as pessoas sem afetar a sintaxe que todo mundo já está usando, então vamos fazer isso!

_> Estou um pouco preocupado que a implementação eventualmente se torne muito complexa._

sim. Sempre existe o risco de maior complexidade ao adicionar novas funcionalidades. Mas, neste caso, não sinto que ainda estamos perto de nenhuma linha vermelha.

E embora a simplicidade no código seja muito valiosa, eu também acho que é muito mais importante estar do lado do usuário do que do lado da implementação 9 em cada 10 vezes.

Eu estava lendo antes deste post sobre a filosofia de design do Sass , e gostei especialmente do questionário que eles usam para decidir se incluem novos recursos ou não. E acredito que esse recurso específico passa pelo desafio.

E também sei que esse código pode ser mais poderoso. Poderia ser mais modular, com funções auxiliares, permitindo listas aninhadas e aliases fazendo referência a outros aliases, mas não estou convencido de que precisa disso. Um nível aninhado é bastante simples, fácil de entender e certamente atende a 99% das necessidades.

_> Se isto em particular for útil sem afetar a sintaxe (...) então vamos lá! _

sim. Isso não afeta a sintaxe anterior e com certeza abre maneiras úteis de usá-la. Vou fazer um novo PR!

Também estou preocupado porque include-media se tornará muito complexo. Gosto da ideia original da biblioteca, é simples e elegante.

Boas notícias, pessoal!

Acabei de descobrir como fornecer uma lista de parâmetros para uma função / mixin do Sass e interpretá-los como listas de argumentos, sem modificar nenhum código existente. Apenas acrescentando três pontos ( ... ) ao final do argumento passado:

$lap: ">phone", "<=tablet";

<strong i="8">@include</strong> media($lap...) {
  color: red;
}

_Exemplo: essência SassMeister _
_Fonte: Sass 3.2, Passando uma lista como argumentos _

Portanto, não parece mais haver necessidade do PR apenas para oferecer suporte a essa funcionalidade. A menos que você decida que deseja a sintaxe _nicer_, é claro.

Brilhante! Eu gosto disso.

Dessa forma, podemos oferecer suporte a aliases sem nenhuma alteração na implementação.

@hudochenkov, você está feliz com isso?

Esta é uma descoberta interessante, @joseluis!

Mas parece hackeado. Na folha de estilo típica de um site responsivo, você precisa digitar muito media($lap...) . Será melhor ter uma sintaxe limpa e consistente ( media("lap") ) em todas as folhas de estilo.

Eu discordo de @hudochenkov neste ponto. Eu acho que os benefícios de ser capaz de escrever <strong i="6">@include</strong> media("lap") {} vez de <strong i="8">@include</strong> media($lap...) {} são insignificantes, especialmente quando se considera a quantidade de alterações de código necessárias para que a implementação atual funcione.

Além disso, o fato de você ter que digitar $lap... sempre deixa claro que você está usando algo diferente da sintaxe usual, então, esperançosamente, ficará claro que você está usando um alias.

Por mais que eu queira contribuir com este projeto, estou com

Você contribuiu, @joseluis. Obrigado pelo esforço que você fez!

Vou adicionar um exemplo deste caso de uso para incluir-media.com .

Não vou insistir em adicionar aliases “nativos” para incluir mídia.

Obrigado, @eduardoboucas , por incluir media. É uma abordagem realmente flexível para consultas de mídia :)

Obrigado, @joseluis , por toda sua ajuda! Vou usar seu PR como aliases para meus projetos :)

Olá a todos,

Em primeiro lugar, gostaria de agradecer por esta incrível biblioteca Sass: smiley:

Comecei tarde no Sass, mas estou adorando o que estou aprendendo e é tudo ótimo: sorriso:
E esta biblioteca torna tudo muito mais fácil lidar com consultas de mídia !!

Ainda assim, esse problema com todos os seus comentários realmente acabou ajudando porque, apesar da descrição dos recursos em include-media.com, o exemplo sobre aliases de Expressão foi, sinto dizer, um pouco enganador.

Não me interpretem mal, o exemplo em si está certo, mas o ... no <strong i="12">@include</strong> media($param...) {} do exemplo passa despercebido pelo leitor: confused: - pelo menos esse é o meu assumir isso. Só depois de ler esse problema e ler o comentário de @joseluis sobre os três pontos, é que tomei
Acho que é mais ou menos como o que @hudochenkov sugeriu e instintivamente
Mas não me interpretem mal, não me importo de usar ... , concordo que é perfeitamente aceitável em vez de ter que reescrever uma tonelada de código apenas para ser capaz de omitir os pontos - simplesmente não seja prático.

Minha única sugestão para @eduardoboucas é incluir um aviso para os

Você pode criar apelidos para expressões que reutiliza muito, não importa o quão complexas sejam. Mas observe os três pontos após o parâmetro $ my-weird-bp , pois eles são obrigatórios.

De qualquer forma, só queria compartilhar um pensamento que pode ajudar outros na leitura de sua documentação. Mais uma vez, muito obrigado por esta biblioteca e continue o excelente trabalho. : simple_smile:

Obrigado @mformigo , vou deixar o exemplo mais claro.

Feito! Obrigado por sinalizar este problema. Espero que fique mais claro: