一文详解sass新特性——模块

最新推荐文章于 2024-06-24 22:57:31 发布

十方魔

最新推荐文章于 2024-06-24 22:57:31 发布

阅读量3.2k

点赞数 2

分类专栏：前端/CSS 前端/打包压缩/webpack 文章标签： sass css webpack @import 模块化

本文链接：https://blog.csdn.net/github_36487770/article/details/103346303

版权

简介

2019年十月一号，sass团队推出了sass的模块化机制，通过新关键词@use、@forward，变量、mixin和函数从此拥有了命名空间。并且，sass对已有的内置函数进行了归类和整理，分类到了各个内置模块下。

引入模块化机制，让sass向更成熟的阶段迈进了很大的一步。目前sass的各个实现中，仅Dart Sass 1.23.0完全支持这些新特性。sass团队宣称两到三年后才会完全废弃@import等旧语法，现在处于新旧语法共存的过渡时期。

compatibility

sass的模块化机制显然是一个major的提升，那么，如此大费工夫，它能够解决什么痛点呢？让我们先来看看之前的@import所带来的问题吧！

@import主要有以下5个缺点：

无法知道变量、mixin、函数具体是在哪里定义的。比如说，a.scss文件中定义了变量 $h e i g h t ， b . s c s s 文件中引入了 a ， c . s c s s 文件又引入了 b ，那么在 c 文件中，$ height是可用的，但无法确定其来源。
嵌套import会导致重复的css代码，还可能引发奇怪的副作用。设想这样一个场景，一个页面中动态引入了一个组件，页面本身需要加载page.css，组件的样式由component.css决定，而这两个样式表的源scss文件中都用到了common.scss，那么在动态引入组件的时候，common.css中的样式就会被重复加载，可能对原有的样式造成覆盖。
因为没有命名空间，css中的选择器又天然是全局的，为了避免撞名，不敢使用简写的class name，因此起名总是非常冗长。
没有私有函数的概念。库作者无法确保他们的私有工具函数不会被使用者直接获取，直接使用私有函数可能导致混淆和向后兼容的问题。
@extend规则可能会影响到样式中的一切选择器，而不是仅仅是作者所希望的那些。（对@extend不熟悉的童鞋可以看看这篇文章the-benefits-of-inheritance-via-extend-in-sass来具体了解下其使用场景和优缺点。）这一点会在下一节详细论述。

天天写@import，没想到它存在的问题还真不少。那么，sass又推出了什么样的功能，能够替代@import呢？下面，我们来详细解剖一下sass的模块化机制。首先，就从@import的替代者———— @use说起。

@use将取代@import，使css，变量，mixin, 函数都可以在不同的样式表中复用。一个样式表文件就

关注