Angular-cli: Usando variables scss globales en mis estilos de componentes.

No existe tal funcionalidad en la CLI en sí, no. Hay compilación sass pero eso es todo.

@ a5hik Una solución temporal para eso es hacer un _varaibles.scss e importar donde quiera que use sus variables. No es la forma más limpia.

Lo que sugirió @AmarildoK podría incorporarse como una característica en CLI angular. Podría haber un archivo scss compartido en alguna parte y los nuevos archivos .scss en los componentes generados podrían tener una línea de importación para incluir el archivo scss compartido de forma predeterminada.

Sip. Ciertamente necesito esta característica.

¿Todavía nada?

¿Alguna actualización sobre esta gente?

¿Algún avance en esto?

Soy bastante nuevo en el frontend, pero estoy tratando de declarar algunas vars SCSS globales para mi aplicación Angular, y solo quiero estar seguro de que no se pretende que lo que estoy haciendo funcione.

Estoy ejecutando angular-cli 1.0.0-beta.21 . En mi archivo angular-cli.json, en aplicaciones [0] .styles, hago referencia a mi archivo styles.scss .

styles.scss

<strong i="11">@import</strong> url('https://fonts.googleapis.com/icon?family=Material+Icons');
<strong i="12">@import</strong> url('https://fonts.googleapis.com/css?family=Droid+Sans:400,700');
<strong i="13">@import</strong> '_vars';
<strong i="14">@import</strong> 'reset';
<strong i="15">@import</strong> 'global';
<strong i="16">@import</strong> 'index';

_vars.scss

/* VARIABLES  */
/* brand colors */
$color-accent: #2980b9;
$color-primary: #ecf0f1;
$color-subtle: #aaaaaa;

/* rarity */
$color-rarity-legendary: #4c139d;
$color-rarity-ascended: #fb3e8d;
$color-rarity-exotic: #ffa405;

Cuando intento hacer referencia a una variable declarada de esta manera en el archivo .scss un componente, la consola informa que la variable no ha sido declarada.

¿Está fallando debido a algo que estoy haciendo mal o no es posible con la versión actual de la CLI?

Muchas gracias por tu tiempo y ayuda.

¿Alguien puede explicarme cómo ocurre el transpiling SASS?
Supongo que esto sucede:

1. ng-cli transpila el archivo sass global a css
2. encuentre todos los componentes específicos de sass y transpílelos a css
3. concatenar todo ese css

¿Es eso correcto?

Tengo el mismo problema con las variables sass globales. También el transpile es para mí en este momento una caja negra

Lo que hacemos es crear una carpeta llamada compartida y debajo de ella una carpeta de estilos. Luego creamos nuestro descaro allí. Finalmente, desde su componente de nivel superior, normalmente "app.component.scss" simplemente importe.

<strong i="6">@import</strong> './shared/styles/default';

Olvidé que también en el componente de nivel superior necesita configurar Ver Encapsulación.

encapsulation: ViewEncapsulation.None

@greenchapter sí ... Desearía que hubiera una buena documentación para ello. si encuentra algo, hágamelo saber.

@ ahmed-musallam vea mi ejemplo anterior. Había olvidado la bandera de encapsulación en el componente raíz. Solo recuerde que app.component.scss no se encapsulará, por lo que cualquier estilo importado se propagará a cualquier componente secundario, etc.

En muchos casos, esto funciona bien, veo un pequeño problema con él. todavía puede tener estilos encapsulados para componentes.

Incluso con el conjunto de encapsulación, sigo recibiendo un error var faltante en la compilación. ¿Hay algo más que deba configurarse?

@askdesigners es difícil de decir que necesito verlo. El ejemplo anterior que mostré funciona bien, ¿es posible que haya algo con tu descaro? Tal vez publique algunas capturas de pantalla o algo y tal vez algo se destaque.

@ origin1tech @askdesigners no debe deshabilitar la encapsulación. Es malo cuando tienes CSS con fugas.

Si conoce SASS, sabrá que la variable y la declaración mixin NO se transfieren a CSS. Así que no hay problema con hacer lo que @AmarildoK sugirió anteriormente. simplemente haga que las variables y los mixins sean parciales e inclúyalos cuando lo necesite. Dado que los vars y los mixins no se transpilan a menos que los use, no hay gastos generales aquí.

Lo que @ a5hik está pidiendo en el hilo es solo por conveniencia ... si usa angular, ya está familiarizado con los pasos ceremoniales de angular para crear componentes y servicios ... esto es lo mismo ... Además, no creo que el El transpilador SASS admite la inyección de variables sobre la marcha (durante el transpilado). la única manera de hacerlo es escribiendo una declaración de importación en cada archivo sass antes de la transpilación de SASS. Y esto se puede hacer mediante un script de nodejs si debe tener esa conveniencia.

@ ahmed-musallam es sólo una "fuga" si no la define.

No tiene nada de malo tener algunos estilos que sean globales para su aplicación por conveniencia. Si ese no fuera el caso, cli no se compilaría con un archivo de estilos globales preconfigurado ni la opción de encapsulación estaría disponible. La desactivación en un componente de nivel superior no niega la encapsulación en los subcomponentes.

Si no es lo que prefieres, lo entiendo, pero sugerir enfáticamente que está mal es absurdo. Sería innecesario tener una tarea de compilación / configuración separada solo para esos pocos estilos globales.

@ origin1tech por supuesto! debe usar CSS global cuando necesite estilos globales. Obviamente, no hay duda. Y no repetiría el mismo CSS en todos los componentes en lugar de usar un estilo global.

pero cuál es su ejemplo, acerca de configurar encapsulation: ViewEncapsulation.none no funciona como lo describió ni estaba destinado a usarse de esa manera. la buena gente de rangle.io explica la diferencia en los tres métodos de encapsulación aquí: https://angular-2-training-book.rangle.io/handout/advanced-components/view_encapsulation.html. También Pascal Precht tiene un artículo realmente bueno en Thoughtram.io que describe eso también: https://blog.ilsttram.io/angular/2015/06/29/shadow-dom-strategies-in-angular2.html

de todos modos, no estamos hablando de "estilos globales" en este hilo, estamos hablando de "variables sass" y de encontrar una manera de reutilizarlas en todos los componentes.

Lo que hacemos es que definimos un base.sass, que no genera ningún CSS sino que solo define variables globales.

Esta hoja de estilo se importa luego sobre las hojas de estilo sass del componente.

<strong i="7">@import</strong> "./src/assets/private/sass/base";

No genera ninguna sobrecarga de CSS en los componentes, puede dejar ViewEncapsulation habilitado y todo está bien.

Ahh, este es un problema frustrante. Solo quiero importar colores y cosas una vez. No en todos los archivos scss.

No estoy tan convencido del tren CSS encapsulado. Tengo la idea, pero honestamente, si escribes un buen CSS modular reutilizable desde el principio, no es un problema en absoluto. Solo es un problema cuando realmente no obtienes la cascada. BEM resuelve este problema bastante bien en mi opinión sin ningún tipo de encapsulación.

Sí, es un poco frustrante, pero así es como funciona scss. Lo que no entiendo es por qué los estilos de componentes siempre están en línea. Si estuvieran concatenados a style.scss global (antes de ejecutar sass) en cambio, no tendríamos problemas con variables indefinidas o mixins.

Debajo de eso, no hay mapas de origen para los estilos en línea.

Veo que hay mucha gente que tiene el mismo problema aquí. Entiendo que Angular CLI se hace como está (tómalo o déjalo). Pero al no escuchar a tanta gente solicitando una forma más pragmática, la definición de la pila de herencia + de Sass parece más un capricho que un problema técnico (¿debería tener que decir qué significa CSS?).

Es bastante lógico pensar que a un desarrollador le gustaría manejar esto de una manera reutilizable, evitando la sobreimportación y aprovechando al máximo la cascada de estilos.

Espero que el equipo de Angular CLI entienda que esta es una crítica constructiva de alguien, como muchos otros, que no ve una buena razón por la que no seguir adelante con una función tan demandada.

Espero ver esta función implementada pronto. Es muy frustrante escribir esa declaración de importación para cada estilo de componente.

¿Cómo se arreglaría esto? El compilador no incluye sus variables, solo compila cada componente-scss por separado. Por lo tanto, debe incluir sus variables / mixins / funciones. Así es como funciona sass y escribir esa declaración de importación es la forma correcta.

Espero que solucionen este problema pronto. En caso de que necesite importar su sass, Webpack proporciona una mejor manera de hacerlo:

@importar “~ variables.scss”;

Es menos frustrante que especificar la ruta completa.

¿Se viene una solución o se debe utilizar la "solución alternativa" descrita aquí?

Parece que todavía no hay una "solución". Pero en cualquier caso, no use la sugerencia con encapsulation: ViewEncapsulation.None menos que realmente comprenda sus implicaciones.

Hay una forma sencilla de lograrlo.
Agregue la siguiente propiedad en .angular-cli.json en "aplicaciones":

      "stylePreprocessorOptions": {
        "includePaths": [
          "scss"
        ]
      }

Esto supone que su scss está en una carpeta bajo src llamada scss .

@hellofornow , lo anterior no pareció funcionar para mí. ¿Hay alguna trampa?

@gustavossantos sin

src/ 
 scss/
   - variables.scss
 app/
   components/
     - component1.ts
     - component1.html
     - component1.scss
.angular-cli.json

El contenido de angular-cli.json es como se describe arriba.
El contenido de component1.scss sería:

<strong i="13">@import</strong> 'variables';

...rest of your scss goes here

Mis dos centavos:

Probé las variables nativas de CSS y funcionan bien con Angular y SCSS (también para aquellos que usan Prettier o algo).
¡Pruébalos! Son nativos, por lo tanto compatibles fuera de SCSS.

https://css-tricks.com/difference-between-types-of-css-variables/

@hellofornow esto significa que cada archivo importaría un archivo variable en cada componente, ¿verdad? No creo que eso sea lo que OP quería

Ahora mismo importo las variables.scss manualmente en cada archivo scss que lo requiera.

@hellofornow ¿cuál es el beneficio de cambiar angular-cli.json si puedo lograr lo mismo sin él y usando <strong i="7">@import</strong> “~variables.scss”; , como escribió @antoniocastanheira ?

Además, en general, no veo ningún problema en implementar _algo_. Sin embargo, podría haber algunas implicaciones, es decir, ¿cómo se manejan los módulos de carga diferida?

Sugiero una discusión sobre can we do something about it and if, how y en qué casos extremos debemos pensar en lugar de do it now .

@ daniel-seitz tal vez un poco de confusión: este número trata sobre muchos temas diferentes.

Usar <strong i="6">@import</strong> “~variables.scss”; es excelente si su scss está dentro de una carpeta dentro de node_modules (no modificable).

Es necesario agregar scss rutas en angular.cli.json si desea importaciones "simples" para scss que están definidas en su proyecto.

Sin agregar las rutas scss apropiadas en angular.cli.json , tendrá que realizar importaciones de rutas relativas.
Por ejemplo:
<strong i="16">@import</strong> "./src/assets/private/sass/base"; debería simplificarse en <strong i="18">@import</strong> "base";
(suponiendo que haya agregado la entrada correcta en .angular.cli.json)

En cuanto a la importación automática de variables o base en todos los archivos scss, esa puede ser una buena característica.
Se podría hacer de manera similar a este comentario:
https://github.com/webpack-contrib/sass-loader/issues/218#issuecomment -266669156

Creo que si se agregara esta característica, tendría que ser una nueva propiedad de .angular.cli.json .

Gracias por la respuesta @hellofornow. Yo también agradecería esta característica, sin embargo, desde mi entendimiento actual, no es trivial implementar esto.

No fui lo suficientemente claro con mi pregunta para ti, así que una aclaración: Look out for the ~ symbol .

Si uno solo importa así <strong i="8">@import</strong> “variables.scss”; , entonces sí, este archivo debe estar dentro de node_modules, lo cual es malo, no hagas esto.

¡PERO! si hace <strong i="11">@import</strong> “~variables.scss”; , entonces con ~ , entonces puede importar en relación con su carpeta src. Eso es todo, ninguna otra configuración. (Como estamos en el repositorio de angular-cli aquí, no entraré en otras estructuras y lo que necesitamos para configurar esa ruta de inicio)

Teniendo eso en cuenta, ¿cuál es la necesidad de hacer esto entonces? No encontré documentación.

"stylePreprocessorOptions": {
    "includePaths": [
        "scss"
    ]
}

Luego también hice algunas pruebas (también con módulos de carga diferida, ...) y, como todos sabemos, no esperaríamos que esto suceda: Angular CLI con compilación Sass encapsula los estilos para que no tengan efectos en otros partes del sistema.

Cuando usamos la importación, evitamos esto y podemos usar todas las variables, sin embargo, cuando mezclamos variables con CSS real, también podemos hacer cascada.

El PROBLEMA aquí es que cada vez que se usa la importación, ese 'css real' ingresa al archivo resultante en línea, una y otra vez, lo que nuevamente va en contra de la cascada y, lo que es peor, hace que nuestra distribución sea más grande.

La SOLUCIÓN sería poner las variables (mixins, ...) a disposición de la compilación para que las conozca y traduzca sobre la marcha, nada más.

Me gustaría tener estas variables, o al menos el punto de partida, en src / styles.scss, ya que está predeterminado, pero es probable que deba ser configurable.

Si encuentro el tiempo, profundizaré porque sé que no somos solo nosotros los que queremos esto ...

¿Me equivoco o el comentario de AlexHenkel el 23 de enero resuelve el problema?

Tengo mi _variables.scss definido

$primary:rgb(211, 14, 127) !default;

Entonces puedo usar esta variable en un componente

.navbar-light .navbar-nav .active a::after {
    border-bottom: 5px solid var(--primary);
  }

.user-view
{
    background-color: var(--primary);
    color: white;
}

Para aclarar, mi styles.scss se ve así:

<strong i="13">@import</strong> 'variables';
<strong i="14">@import</strong> '../node_modules/bootstrap/scss/bootstrap';

No estoy seguro si OP tuvo el mismo problema pero funciona para mí, porque no tengo que codificar el color predeterminado

Lo siento si esto está fuera de tema, pero según tengo entendido en este hilo, parece que SASS procesa los archivos de forma más aislada, luego diga MENOS, ¿sería correcto?

En esencia, el caso de uso es poder usar un @mixin que establece algunas variables de color en un archivo a un nivel de "aplicación", y esperar esa cascada hacia todos los demás componentes (incluso si _node_modules_) .

_variables.css_

$color: 'green';
$theme: 'generic';

<strong i="9">@mixin</strong> setTheme($theme: 'generic') {
  @if($theme == 'a') {
    $color:  red;
  }

  @if($theme == 'b') {
    $color: blue;
  }
}

_app.component.css_

<strong i="13">@import</strong> "~bootstrap/scss/bootstrap.scss";
<strong i="14">@import</strong> "./styles/variables.scss";

<strong i="15">@include</strong> setTheme('a');

_header.component.css_

<strong i="19">@import</strong> "./styles/variables.scss";

<strong i="20">@include</strong> setTheme('a');  // only changes red if this is set manually, which is hardcoded and not ideal for a reusable component from npm

h1 {
  color: $color;
}

En este caso, cualquier cosa procesada en el componente de mi aplicación usando $color cambiaría a rojo, pero nada en mis otros componentes no cambiaría de color (seguiría siendo el color predeterminado de verde) a menos que llame manualmente a setTheme en todos mis componentes, lo que no los hace muy reutilizables.

Gracias y espero que no haya sido demasiado confuso. ¡Cualquier pensamiento será muy apreciado!

Pude hacer que algo funcionara para mi caso de uso usando sass-vars-loader .

Solo un FYI, parece que usar la tilde para hacer referencia a 'src' desde el nivel de componente ala <strong i="5">@import</strong> '~scss/variables'; tiene errores (no funciona) en Angular 6 ( problema ). <strong i="8">@import</strong> '~src/scss/variables'; embargo, <strong i="10">@import</strong> './src/scss/variables'; parecen funcionar. Solo un anuncio de servicio público si alguien tiene problemas.

No puedo creer lo difícil que hace Angular usar SASS. Estoy a punto de cambiar a React / webpack

esta es una de las cosas más comunes que puedo imaginar. ¡¿Cómo puedes equivocarte ?!

también: puede hacer que esto funcione fácilmente a través de webpack y el propio sass-loader. Hombre, sería genial si ng cli ofreciera una forma de extender la configuración del paquete web desde el primer momento. Como lo hace Vue.

Chicos, así es como funciona sass / scss y no tiene nada que ver con Angular. Simplemente importe sus variables y estará listo para comenzar O use un archivo de hojas de estilo global.

Entonces, en conclusión, si @import algo pero no usa una var o una mezcla de lo que ha importado, no está incluido en el paquete final, ¿verdad?

¿Hay alguna forma de usar variables sass globalmente sin la necesidad de importar manualmente en cada componente? Quizás esto sería una mala práctica de todos modos, ya que todos los componentes tienen acceso, incluso si no lo necesitan ...

Haz una cosa. Funcionará.
importar variable.scss archivo en el componente donde desea usar variables, funcionará.
Esto no es estándar, si llega algo estándar, se puede deshacer fácilmente.

¿Qué sucede si quiero paquetes css separados, que puedo cambiar en tiempo de ejecución, cada paquete usando su propio _variables.scss?

Este problema se ha bloqueado automáticamente debido a la inactividad.
Por favor, presente un nuevo problema si encuentra un problema similar o relacionado.

Obtenga más información sobre nuestra política de bloqueo automático de conversaciones .

_{_Esta acción ha sido realizada automáticamente por un bot._}