更少:如何从地图中获取整个规则集 [英] Less: how to grab an entire ruleset from within a map

问题描述

我有一个嵌套的规则集(地图)，如下图所示.

I have a nested ruleset (map) like the one below.

@typography: {
    @h1: {
        font: roboto;
        font-weight: 300;
        font-size: 9.6rem;
        line-height: 9.6rem;
        text-transform:none;
    }
}

我知道如何检索和输出诸如[font]之类的单个键，但是有什么方法可以返回和输出整个内部规则集?

I know how to retrieve and output a single key such as [font], but is there any way of returning and outputting the whole of inner ruleset?

.myclass {
    font: roboto;
    font-weight: 300;
    font-size: 9.6rem;
    line-height: 9.6rem;
    text-transform:none;
}

推荐答案

当前无法以这种方式工作(v3.9)".

恐怕它无法正常工作(特别是地图本身). 凭直觉，它会是这样的:

"Can't work this way currently (v3.9)".

I'm afraid it's not going to work the way (specifically the map itself) it is. Intuitively it would be something like:

#usage {
    @typography[@h1]();
}

但是目前尚未实现此功能(级联()和[]运算符).

But currently this feature (cascading () and [] operators) is not implemented.

诸如将感兴趣的规则集分配给临时变量然后'调用'之类的"第一猜测的解决方法也失败了:

A first-guess workaround like "assign a ruleset of interest to a temporary variable and then 'call' it" also fails:

#usage {
    @temp: @typography[@h1];
    @temp(); // error: not callable value
}

(这个实际上算作一个错误-我已创建专用票).

(This one actually to be counted as a bug - I created a dedicated ticket).

所有这些将我们带到下一部分:

This all brings us to the next section:

请注意，尽管到目前为止基于变量的映射"(又名DR)似乎是一种分布更广泛的模式，但仍有

Notice that while "variable-based maps" (aka DRs) seem to be a more wide-spread pattern by now, there are five different methods to define a map in Less (and infinite number of these methods permutations to define an N-dimensional (aka "nested") map).

每种方法都有其优点和缺点，到目前为止，尚不清楚哪种方法被选为首选"方法(从长远来看，趋向于使它们尽可能整齐地统一，但到目前为止还很遥远)那).

Each method has its pros and cons, and so far it's not clear which one to be chosen as the "go-to" one (in a long run there's tendency to unify them as tidy as possible but so far it's far from that).

现在查看您要表示的结构，该结构不遵循变量-> @variable"构造型.它看起来不像常规的CSS规则集吗?

Now look at the structure you're trying to represent w/o sticking to "variable -> @variable" stereotype. Does not it look like a regular CSS ruleset:

.typography {
    .h1 {
        font:         roboto;
        font-weight:     300;
        font-size:    9.6rem;
        line-height:  9.6rem;
        text-transform: none;
    }
}

?

通过这种方式，您已经具有基于混合图的映射"，您可以使用与使用基于变量的映射"几乎相同的方式. (实际上，地图"的当前文档也建议这两种方法均不强制使用这两种方法作为主要").
您需要对该"CSS"结构进行的唯一修改是使其内部或外部(或两个)规则集成为参数混合(通过添加())，以使规则不会出现在已编译的CSS中，默认.

And this way you've already got a "mixin-based map" you can use pretty much the same way you'd use a "variable-based map". (Actually the current documentation for "Maps" also suggest both methods w/o enforcing either one as "the primary").
The only modification you'll need for this "CSS" structure is to make its inner or outer (or both) rulesets to be a parameteric mixin (by adding ()) so that the rules won't appear in the compiled CSS by default.

例如像这样:

.typography {
    .h1() {
...

或者像这样:

.typography() {
    .h1 {
...

(如果您更喜欢这些标识符，也可以使用#而不是.).

(Also if you prefer for these identifiers you can use # instead of .).

现在回到您的用例(解决方案):

Now getting back to your use-case (The Solution):

.typography {
    .h1() {
        font:         roboto;
        font-weight:     300;
        font-size:    9.6rem;
        line-height:  9.6rem;
        text-transform: none;
    }
}

#usage-1 {
    // "expand" the set of rules:
    .typography.h1(); // OK
}

#usage-2 {
    // use individual value from the map:
    r: .typography.h1[font]; // OK
}

#usage-3 {
    // iterate through:
    each(.typography.h1(), <...>); // OK
}

// etc.

毫不奇怪，扩展一组规则才是混入首先被发明的目的.

Not a surprise counting that expanding a set of rules is what the mixins were invented for in the first place.

要记住的基于变量"和基于混合素"的映射之间唯一的根本区别(除了当前的局限性/如何使用它们)是变量(和属性)覆盖" 和规则集(进而是mixins)级联" .当您需要通过外部代码"对CSS数据进行自定义/修改时，这可能会影响某些特定的细节(例如，在主题/子主题"等中)，但这是另一个大故事，因此我不再赘述在这里，尽管有些技巧请参见下一节.

The only fundamental difference (beside current limitations/issues on how they can be used) between "variable-based" and "mixin-based" maps to keep in mind is that "variables (and properties) override" and "rulesets (and thus mixins) cascade". This may affect some particular details when you'll need your CSS data to be customized/modified by "external code" (e.g. as in "theming/subtheming" etc.) - but that's another big story so I won't get into it here, although see the next section for some tips.

(在用例的背景下)还有另外一件事需要了解关于mixin.

And one more important thing to understand about mixins (in context of the use-case).

如果我们将变量视为抽象的编程事物，即与值关联的标识符(符号名称)"，我们很快就会看到 mixin 就是: a变量.

If we'll think of variables as an abstract programming thing, i.e. "an identifier (symbolic name) associated with a value" we quickly see that a mixin is just that: a variable.

"mixin"(其名称)实际上只是用于引用值的标识符，即-> 变量.

A "mixin" (its name) is really nothing but an identifier to refer to a value, i.e. -> variable.

仅仅是标识符字符(前面是#或.)，加上对它可以容纳哪种值的限制，这使得它必须由不同的标题来引用，即"mixin"而不是变量"(如"Less @variable"中所述).

It's just the identifier characters (# or . in front) plus a limitation on what kind of values it can hold is what makes it to be referred to by a different title, i.e. "mixin" instead of a "variable" (as in "Less @variable").

换句话说，当涉及到我有一些数据并且我需要一些东西(即" a 变量")来保存/表示它"时，重要的是不要自动落入" a 变量(一般意义上)-> @variable陷阱.

In other words, when it comes to "I have some data and I need something (i.e. "a variable") to hold/represent it", it's important to not automatically fall into the "a variable (in a generic sense) -> @variable" trap.

因此，回到Q时，要记住的另一个技巧是知道可以(几乎)自由地相互分配混合值和变量值(特别是如果它是规则集"值). IE.基本上，您可以创建一个变量来引用基于mixin的映射，并创建一个mixin引用基于变量的映射. 这对于克服这两种方法的当前问题/局限性(主要是在使用中)可能是有价值的(或者，如果您只是更喜欢使用映射的@，.或#代码外观"，则可能更有价值).

So getting back to the Q, another trick to have in mind is to know that mixin and variable values (specifically if it's a "ruleset" value) can be (almost) freely assigned/reassigned to each other. I.e. basically, you can create a variable to refer to a mixin-based map and create a mixin to refer to a variable-based map. This may be valuable to overcome current issues/limitations (mostly in usage) of both methods (or if you just prefer more of @, . or # "code-look" where maps are used).

以下是一些提示:

// ................
// "Universal" map:

.typography {
    .h1() {
        font:         roboto;
        font-weight:     300;
        font-size:    9.6rem;
        line-height:  9.6rem;
        text-transform: none;
    }


    @h1:  {.typography.h1}; // assign mixin to variable
    .h2() {@h1()}           // assign variable to mixin
    .h3() {.typography.h1}  // assign mixin to mixin
    @h2:  @h1;              // assign variable to variable
}

@typography:  {.typography}; // assign mixin to variable
.graphytypo   {.typography}  // assign mixin to mixin
// etc.

// ................
// Usage:

#usage-1 {
    // use individual values from the map (all roboto):
    1: .typography.h1[font];
    2: .typography[@h1][font];
    3: .typography.h2[font];
    4: .typography.h3[font];
    5: .typography[@h2][font];

    6: @typography[@h1][font]; // <- like your original map

    7: .graphytypo.h3[font];

    // etc.
}

#usage-2 {
    // expand a set of .h1 rules (all the same):
    .typography.h1();
    .typography.h2();
    .graphytypo.h3();
    // etc.
}

这篇关于更少:如何从地图中获取整个规则集的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！