vue 看sass版本
As the size and complexity of a project grows, you require some sort of logic to structure your Sass files. It helps to follow some agreed upon guidelines for creating files and folders when working in large teams and projects. Below is a review of some of the techniques in use today.
随着项目的规模和复杂性的增长，您需要某种逻辑来构造Sass文件。 在大型团队和项目中工作时，它有助于遵循一些公认的准则来创建文件和文件夹。 下面是当今使用的一些技术的回顾。
Bootstrap’s intention is to be a UI library for web developers to quickly get off the ground. It is logical for them to group all variables in a single file and keep all the mixin logic hidden. Their Sass architecture mimics this idea. Each component gets its own Sass file and there’s a ./_variables.scss file, which allows you to control all the variables involved with your project.
Bootstrap的目的是成为Web开发人员可以快速起步的UI库。 对于他们来说，将所有变量分组到一个文件中并保留所有混合逻辑是合乎逻辑的。 他们的Sass体系结构模仿了这个想法。 每个组件都有自己的Sass文件，并且有一个./_variables.scss文件，该文件可让您控制项目所涉及的所有变量。
Bootstrap’s Sass architecture is unique in how it lays out its mixins. There’s a ./_mixins.scss file. This file imports all files from a mixins folder, which contains a separate file for every mixin used. Although button styles are defined in ./_buttons.scss, the mixins used for it are imported from ./_mixins.scss. This, in turn, imports the button mixins frommixins/_buttons.scss. Yo Dawg!
Bootstrap的Sass体系结构在布局其混合模块方面是独特的。 有一个./_mixins.scss文件。 该文件从mixins文件夹导入所有文件，该文件夹为每个使用的mixin包含一个单独的文件。 尽管按钮样式是在./_buttons.scss中定义的，但用于它的mixins是从./_mixins.scss中导入的。 反过来，这又从mixins/_buttons.scss导入按钮mixins。 哟道 ！
In addition to component-level mixins, the mixin folder also contains global mixins such as mixins/_border-radius.scss and mixins/_responsive-visibility.scss. Although bootstrap’s mixins are not overly complex, this architecture is better suited for a project where the mixins are really complex and require that they be broken down into smaller bits. Or in cases where you want to keep that logic hidden from visual styles of components. In conclusion, this architecture works best for Bootstrap but might not work for your sass project.
除了组件级的mixin外，mixin文件夹还包含全局mixin，例如mixins/_border-radius.scss和mixins/_responsive-visibility.scss 。 尽管bootstrap的mixin不太复杂，但是此体系结构更适合于mixin 确实很复杂并且要求将它们分解成更小的位的项目。 或者，如果您想使逻辑隐藏在组件的可视样式中。 总之，此体系结构最适合Bootstrap，但可能不适用于您的 sass项目。
Here’s how the folder structure looks:
文件夹结构的外观如下：
bootstrap/ |– bootstrap.scss # Manifest file |– _alerts.scss # Component file |– _buttons.scss # Component file |– _mixins.scss # Mixin file – imports all files from mixins folder |– ... # Etc.. |– mixins/ | |– _alerts.scss # Alert mixin | |– _buttons.scss # Button mixin | |– ... # Etc..Foundation has a well thought out Sass architecture and it works beautifully for customizing, which is one of its biggest strengths. There’s a settings.scss at root level, which allows you to override any variable used for building components. However, each component file contains variables specific to that component.
Foundation具有经过深思熟虑的Sass架构，并且可以很好地进行自定义，这是其最大的优势之一。 在根级别有一个settings.scss ，它允许您覆盖用于构建组件的任何变量。 但是，每个组件文件都包含特定于该组件的变量。
Foundation also abstracts functions used in the project in a separate functions.scss file. This is good because these functions are framework specific and you should not be editing this file.
Foundation还会在单独的functions.scss文件中抽象化项目中使用的functions.scss 。 这很好，因为这些功能是特定于框架的，因此您不应编辑此文件。
All global mixins such as border radius and transition effects are available in components/_global.scss. They are logically structured as follows:
所有全局混合(例如边界半径和过渡效果)都可以在components/_global.scss 。 它们的逻辑结构如下：
- Import - global mixins - Component specific variables (`$button-tny`, `$button-margin-bottom`) - Component specific mixins - Extends - (not the @extend but actual style definitions, where mixins are called)All component-specific variables are defined as !default, so that they can be overridden using the _settings.scss. If you prefer to keep it simple, you can just change the variables in _settings.scss and call it a day. If you feel more adventurous, you could play with component-specific variables and easily be able to change how your components look.
所有特定于组件的变量都定义为!default ，因此可以使用_settings.scss覆盖它们。 如果您希望保持简单，可以只更改_settings.scss的变量并将其命名为day。 如果您喜欢冒险，可以使用特定于组件的变量，并可以轻松更改组件的外观。
Since their components are built out of mixins and variables, it allows for maximum flexibility. A lot of sites built using Foundation don’t end up looking the same.
由于它们的组件是由mixin和变量构建的，因此可以提供最大的灵活性。 许多使用Foundation构建的网站最终看起来都不一样。
You can adopt foundation’s Sass architecture for most small to medium websites. It becomes very easy to get into the scope of any component and have all required variables, mixins, and extends within the same file.
您可以为大多数中小型网站采用Foundation的Sass架构。 进入任何组件的范围并在同一文件中拥有所有必需的变量，mixins和扩展变得非常容易。
Here’s how the folder structure looks:
文件夹结构的外观如下：
foundation/ |– foundation.scss # Manifest file |– foundation | |– _functions.scss # Library specific functions | |– _settings.scss # Change variables for the entire project | |– components | | |– _buttons.scss # Component file (will import _globals.scss) | | |– _globals.scss # Global mixins | | |– _alerts.scss # Component file (will import _globals.scss)Dale Sande, in his presentation “Clean out your Sass Junk-Drawer”, recommends a modular approach to organizing your Sass files. This comes in handy in enterprise-level projects where the number and visual complexity of modules can be pretty high. This approach helps retain all logic related to a module within its own folder, which allows sub-modules to extend and reuse styles in a scoped fashion. It can also be useful in small to medium projects, if you prefer separating presentation from Sass logic in your files.
戴尔·桑德(Dale Sande)在他的演讲“清理Sass垃圾抽屉”中，建议了一种模块化方法来组织Sass文件。 这在企业级项目中非常有用，在这些项目中，模块的数量和视觉复杂性可能很高。 这种方法有助于将与模块相关的所有逻辑保留在其自己的文件夹中，这允许子模块以范围限定的方式扩展和重用样式。 如果您更喜欢在文件中将表示形式与Sass逻辑分开，则它在中小型项目中也很有用。
One of the major advantages to following Dale Sande’s approach is the fact that it makes it easy to create a separate stylesheet for a particular module. Inside your project, you could load one base stylesheet that contains global styles and load another stylesheet specific to the module. This helps remove a lot of bloat from the code, improving performance and load speed.
遵循Dale Sande的方法的主要优点之一是，可以很容易地为特定模块创建单独的样式表。 在项目内部，您可以加载一个包含全局样式的基本样式表，并加载特定于该模块的另一样式表。 这有助于消除代码中的大量膨胀，从而提高性能和加载速度。
Here’s the folder structure:
这是文件夹结构：
sass/ |– style.scss # Manifest |– modules/ | |– registration/ # Sub Module | | |– _extends.scss # Functional | | |– _functions.scss # Functional | | |– _mixin.scss # Functional | | |– _module_registration.scss # Imports functional partials and contains presentational | | |– _module_personalInfo.scss # Imports functional partialsStyle prototypes, by Sam Richard, is a brilliant tool and set of guidelines for design in the browser using Sass and Compass. In this architecture, components are logically grouped under specific folders such as base, components, layouts (SMACSS) or atoms, molecules, and components (atomic design).
萨姆·理查德(Sam Richard)编写的风格原型是一个出色的工具，也是使用Sass和Compass在浏览器中进行设计的一套准则。 在此体系结构中，组件在逻辑上分组在特定的文件夹下，例如基础，组件，布局(SMACSS)或原子，分子和组件( 原子设计 )。
Further, each component gets its own set of partials: _variables.scss, _mixins.scss, _extends.scss and a manifest file (_buttons.scss, _alerts.scss etc).
此外，每个组件都有自己的部分集： _variables.scss ， _mixins.scss ， _extends.scss和清单文件( _buttons.scss ， _alerts.scss等)。
This approach has a couple of disadvantages though:
但是，这种方法有两个缺点：
Compile time – More files require more time to get compiled 编译时间–更多文件需要更多时间来进行编译 It might require a lot of file switching when you build components initially. But once you are done, its a breeze to maintain or make changes. 最初构建组件时，可能需要大量文件切换。 但是一旦完成，维护或进行更改就变得轻而易举。The benefit here is the ability to work on a single portion of a module. It clearly demarcates configuration (variables), functional (mixins, extends), and presentational (component partials) portions used to design a component. Global configurations are kept separate from component/module level configuration.
这样做的好处是可以在模块的单个部分上工作。 它清楚地划分了用于设计组件的配置 (变量)， 功能 (mixin，扩展)和外观 (组件局部)部分。 全局配置与组件/模块级别的配置保持分开。
This separation helps maintain sanity in medium to large projects, where you have multiple teams working on modules. It also becomes easier to create module specific stylesheets, when required.
这种分离有助于在大型项目中保持理智，在该项目中，您需要多个团队来处理模块。 在需要时，创建模块特定的样式表也变得更加容易。
Here’s the folder structure:
这是文件夹结构：
scss/ |– style.scss # Manifest |– partials/ | |– base/ | | |– _content.scss | | |– content | | | |– _variables.scss # Component specific variables | | | |– _extends.scss # Component specific extends | | | |– _mixins.scss # Component specific mixins | |– components/ | | |– _message.scss | | |– message | | | |– _variables.scss | | | |– _extends.scss | | | |– _mixins.scss | |– global/ | | |– _variables.scss | | |– _extends.scss | | |– _mixins.scss | | |– _functions.scss | |– layouts/ | | |– _article.scss | | |– article | | | |– _variables.scss | | | |– _extends.scss | | | |– _mixins.scssI think Hugo does a great job of covering a SMACSS-based approach, which you can read about in his Sass architecture post, so I won’t discuss that here. There’s also a handy SMACSS starter kit by Mina Markham available.
我认为Hugo在涵盖基于SMACSS的方法方面做得很好，您可以在他的Sass体系结构文章中了解到这一点，因此在此不做讨论。 还有Mina Markham提供的方便的SMACSS入门工具包 。
In this article, we looked at different ways to structure your Sass files. To decide which method to use, you need to weigh your options between complexity, compile time, and personal preference.
在本文中，我们研究了构建Sass文件的不同方法。 要决定使用哪种方法，您需要权衡复杂性，编译时间和个人喜好之间的选择。
This becomes tricky when working on teams. Make sure everyone feels comfortable with your approach and feel free to tweak methodologies to suit your specific circumstances.
在团队中工作时，这变得棘手。 确保每个人都对您的方法感到满意，并随意调整方法以适合您的特定情况。
I like the Style Prototypes architecture best because it suits the way I think. The important thing to note is
我最喜欢样式原型架构，因为它适合我的想法。 需要注意的重要一点是
The deeper you nest, the longer it takes to compile.
嵌套的深度越深，编译时间就越长。
Do let us know your project’s Sass architecture in the comments section.
请在评论部分让我们知道您项目的Sass架构。
翻译自: https://www.sitepoint.com/look-different-sass-architectures/
vue 看sass版本
