6 Matching Annotations
  1. Nov 2019
    1. To share variables between Sass files, you can use Sass imports. For example, src/App.scss and other component style files could include @import "./shared.scss"; with variable definitions

      just like we do in other project, say an Angular app. So the React components will use composition but in the sass files, we can use import() and @extends

  2. May 2018
  3. Feb 2017
  4. Feb 2016
    1. This is a perfect use-case for @extend. These rulesets are inherently related; their shared traits are shared for a reason, not coincidentally. Further, we aren’t transplanting their selectors hundreds of lines away from their source, so our Specificity Graph stays nice and sane

      So a sensible policy might be to use @extend only for related classes in the same source file, where source order is obvious.

    2. Some useful notes on the pros and cons of @extend vs mixins in SCSS.

      In a nutshell, he suggests avoiding @extend entirely.

      My main bugbear is that it prevents local reasoning about the final set of rules that will apply for an element with a given class.

    1. n the Webpack approach, each Sass file is compiled in isolation. This isn't a new idea, but I think it's a much better way of doing Sass. It just means you need to @import dependencies like variables & mixins wherever you use them

      Which is a much better thing to be doing anyway in terms of having clear and explicit dependencies.