【问题标题】:Bootstrap LESS: duplicate @importsBootstrap LESS:重复@imports
【发布时间】:2015-04-24 00:26:09
【问题描述】:

我们正在使用引导程序 v3.3.4。

我们的结构将所有引导程序的 LESS 源文件保存在一个单独的文件夹中,以便于升级。

在我们编译为styles.css 的主要styles.less 文件中,我们只是@import 所有依赖项,包括bootstrap.less。

@import "bootstrap/bootstrap.less"; // bootstrap source
@import "variables.less"; // our custom variables
@import "mixins.less"; // our custom mixins
@import "main.less"; // all of our custom css/less styles

我们自定义的variables.less 文件导入bootstrap 的variables.less 文件,我们自定义的mixins.less 文件导入bootstrap 的mixins.less 文件。

这意味着在我们的主 styles.less 中,bootstrap 的 variables.less 和 mixins.less 被导入了两次。 (一次在bootstrap/bootstrap.less 一次在我们的自定义mixins.less/variables.less 中)

我们这样做的原因是因为我们有其他单独的 css 文件,我们只包含在一些页面中以及 styles.css,并且这些文件是从它们自己的 less 文件编译而来的,它们依赖于两者bootstrap 的自定义变量/mixins 和我们的自定义变量/mixins,这意味着它们需要在这些 less 文件中导入。

因此,这样做要容易得多:

@import "variables.less"; // our custom variables that also @import bootstrap's variables
@import "mixins.less"; // our custom variables that also @import bootstrap's variables

并且不必担心单独导入所有依赖项(引导程序和我们的),因为我们的版本会导入引导程序版本。

如果我们尝试消除重复导入,它看起来像:

@import "bootstrap/variables.less";
@import "bootstrap/mixins.less";
@import "variables.less";
@import "mixins.less";

我们不仅要导入两倍多的文件,而且还要担心顺序,因为引导文件必须先出现。

我的问题是 A) 这样做会不会因为重复导入而导致问题,B) 即使它不一定会导致问题,这是否违反任何最佳实践,以及 C) 有没有更好的方法来解决这个问题?

【问题讨论】:

  • "这意味着在我们的主 styles.less 中,...被导入了两次。" "the default behaviour" 的 import 语句。
  • @seven-phases-max 是的,以下答案之一为我清除了这一点。所以现在我只是想知道我的方法是否违反了任何最佳实践,以及是否有更好的方法来做到这一点。
  • 好吧,我个人认为 B 没有违反任何“最佳实践”(您在大多数框架中看到的只是历史上强制的“传统”和“遗留”,因为某些框架的开发其中一些始于石器时代,然后更多年轻的框架只是盲目地复制旧框架的方法。
  • 所以我会这样说:“如果您的任何 '...component.less' 也应该自行编译成相应的 '...component.css' ,它没有任何问题 可以导入所有必需的导入...如果这些组件也被编译为“一体式”样式表的一部分,则可以复制导入”(但是相反的方法也绝对没问题,因此确切的选择完全取决于特定的用例)。但我不想写答案,因为这样的 B 问题在这里非常偏离主题(“主要基于意见”),而且它更像是博客文章的主题。
  • @seven-phases-max 我知道有不止一种“正确”的做事方式,但也有完全错误的做事方式。我的 B 问题是关于主题的,因为如果我所做的事情违反了任何标准的最佳实践,那么无论任何人对正确做法的个人意见如何,都可能被认为是错误的。

标签: twitter-bootstrap twitter-bootstrap-3 less


【解决方案1】:

A) 以我们的方式这样做会因为重复导入而导致问题吗?

首先,答案是否定的。 LESS 编译器足够聪明,可以关心模块和声明的重复。它能够区分和处理它。

B) 即使它不一定会导致问题,这是否违反任何最佳实践?

当然,除非导入不处理副作用,如果它们只携带不会以任何方式影响任何其他样式的代码,并且如果编译,将生成一个没有声明的 CSS。导入两次充满副作用的代码并不好,不是通过两次代码生成,而是通过良好的实践和易读性。

C) 有没有更好的方法来解决这个问题?

是的,您应该知道 LESS 中的导入是在编译时工作的,当您只编译主文件时,您将能够从外部源访问变量和 mixin。举个例子吧:

palette.less:

@defaultColor: navy;
@secondaryColor: black;

body-def.less:

body {
  background-color: @defaultColor;
  border-top: 5px solid @secondaryColor;
}

ma​​in.less:

@import "palette";
@import "body-def";

html { ...

请注意,body-def 不会导入 palette,但它可以访问其数据,就像编译 main.less 一样。

【讨论】:

  • 感谢您的详细解答。你的A分和B分让我明白了很多。我理解你的 C 点,如果我所有的 less 都被编译成一个 css 文件,那是完全有道理的。但是,在我的问题中,我说我有第二个 .css 文件,它是完全独立的,并且是从不同的 .less 文件编译而来的。这是因为 .css 文件仅在某些页面上需要,而不是全部。第二个 .css 文件仍然需要访问我的主 styles.css 文件中的变量和 mixins。除非我弄错了,否则这意味着我确实需要导入 variables.less 和 mixins.less
【解决方案2】:

A) 这样做会因为重复导入而导致问题

没有

B) 即使不一定会导致问题,这是否违反任何最佳实践

是的。使用 CSS 预处理器的一种常见方法是让一个文件控制所有内容,这是您的 styles.less 文件。心态应该是对所有这些都进行单一的规则,找到它们,然后将它们全部组合在一起(关于进口)。因此,如果您要导入两次或两次以上的内容,那么单个文件不会将它们全部放在一起,也不会找到所有内容。

C) 有没有更好的方法来解决这个问题?

LESS 不像其他面向对象的语言那样工作,您必须导入特定的标头才能使用 mixin。通过简单地编译styles.less(你的主LESS文件),它将自动能够进入Bootstrap并调用正确的mixins。

某些 IDE 无法在没有隐式 @import 的情况下处理来自其他文件的 mixin,因此它不会给您提示,但 LESS 本身可以处理它没有问题;这实际上就是它的本意。如果您需要智能感知提示,您可能只需要为 IDE 找到另一个插件或将 Bootstrap 文档放在您旁边。

您可以采用的一种方法是创建一个可以在项目中使用的“common.less”文件。例如:

common.less

@import "bootstrap/bootstrap.less"; // bootstrap source
@import "variables.less"; // your custom variables
@import "mixins.less"; // your custom mixins

styles.less

@import "common.less";

// Your common CSS

unique.less

@import "common.less"

// Custom CSS per page

使用这种方法,您只需导入一次内容,而不必担心在每个文件中单独管理内容。请确保,您不要在 common.less 中导入任何实际输出 CSS 的 LESS 文件,否则您的 CSS 文件中会有重复的规则。

【讨论】:

  • 感谢您的回答。 B点的更多解释会很好。就你的 C 点而言,如果我所有的 less 都被编译成一个 css 文件,那是完全有意义的。但是,在我的问题中,我说我有第二个 .css 文件,它是完全独立的,并且是从不同的 .less 文件编译而来的。这是因为该 .css 文件仅在某些页面上需要,而不是全部。第二个 .css 文件仍然需要访问我的主 styles.css 文件中的变量和 mixins。除非我弄错了,否则这意味着我确实需要导入 variables.less 和 mixins.less
  • 您将导入所有 bootstrap in common.less,因此每个单独的文件都将包含 bootstrap 的所有 css。
  • @wired_in 哦,对不起!你确实提出了一个很好的观点。看来我的回答用处不大
猜你喜欢
  • 2015-10-29
  • 1970-01-01
  • 1970-01-01
  • 2013-12-30
  • 1970-01-01
  • 2011-08-29
  • 2014-10-31
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多