Merge/add declarations into an existing selector block / :expand( .mergeIntoSelector ) analogous to :extend( .addToSelector )

[krsdcbl]

Outline

I've recently encountered the need to merge properties printed by individual mixin calls into a single selector block, and realised it's likely not possible currently. I'm not certain if this is even feasible to implement, but imagine a possible solution through an API similar to :extend. I'll outline the use case with an example of what I'm currently doing & what I'm trying to achieve:

Problem

I've created a mixin to implement theming in my current utility framework: It allows me do declare variables to be themed as lists instead of disctinct values & generate all available variants for different themes by accessing those LESS variables through a mixin call.

// theme registry
@COLORTHEMES: '', '.theme-primary', '.theme-secondary';
// accessor
.mapByTheme( @property-name, @LESS-var, @themes: @COLORTHEMES ) {
	each( @themes, {
		@theme-selector: e(@value); // sanitize theme selector
		@property-value: extract( @LESS-var, @key); // extract value for respective theme

		// output each variant with the globally specified selector conditions
		@{theme-selector} & { @{property-name}: @property-value; }
	})
}

// usage
@variable-1: red, blue, green;
@variable-2: white, black, grey;
@variable-3: 0.5em, 0.75em, 1em;
.example {
	.mapByTheme( --color, @variable-1 );
	.mapByTheme( --background, @variable-2);
	.mapByTheme( padding, @varialbe-3 );
	color: var(--color);
	background: var(--background);
}

This pattern works beautifully, but leaves the issue of producing individual selector statements for each call of the .mapByTheme() mixin regardless of shared selectors.

// outputs
.example {
  color: var(--color);
  background: var(--background);
  --color: red;
  --background: white;
  padding: 0.5em;
}
.theme-primary .example { --color: blue; }
.theme-secondary .example { --color: green; }
.theme-primary .example { --background: black; }
.theme-secondary .example { --background: grey; }
.theme-primary .example { padding: 0.75em; }
.theme-secondary .example { padding: 1em; }

That doesn't look too problematic with this limited examples, but quickly results in heavy selector bloat throughout a full project, and there seems to currently be no way or practical workaround in less to dynamically add properties to an existing selector.

Proposed solution

Introducing an :expand( intoTargetSelector ) function that accepts interpolated selectors/variables for defining an existing selector to be written to would make this and probably many other issues much easier to handle:

// ... in the mixin, something like (totally pseudocode proposition, idk how an implementation should ideally look like)
	expand( @{theme-selector} ) & { @{property-name}: @property-value; }

// hooks to be expanded into, anywhere else
.theme-primary { } 
.theme-secondary { }

... enabling to produce merged statements as opposed to the current output that writes an individual selector statement for every mixin call:

.example {
  color: var(--color);
  background: var(--background);
  --color: red;
  --background: white;
  padding: 0.5em;
}
.theme-primary .example { 
	--color: blue; 
	--background: black;
	padding: 0.75em;
}
.theme-secondary .example { 
	--color: green; 
	--background: grey;
	padding: 1em;
}

Remarks

• There might very well be some way to achieve what I'm trying to do with existing mixin logic alone. I've tried quite a bunch of ideas and can't come up with a feasible solution, but that doesn't mean it's impossible or that it'd mandate the addition of an own function.
• I also might be overlooking better ideas to enable "merging selectors", coming from a very specific problem I encountered and therefore possibly looking at this issue with a very narrow scope.
• Aside the longtail of logical implications likely needed to be considered, I'm definitely not familiar enough with the inner workings of LESS to be able to gauge if this would be feasible at all, or actually impossible to implement with the way less has to parse & compose selectors/mixins/variables etc.
• If the latter is the case, please be happy to just tell me "that's not how it works lol", close this discussion & leave me to continue handling the consequences of my self-induced selector bloat with minification-tooling / after the build step :D

[matthew-dean]

@krsdcbl It's really a matter of managing loops, as you would in other programming languages.

This input:

@COLORTHEMES: '', '.theme-primary', '.theme-secondary';
// accessor
.mapByTheme( @dr, @themes: @COLORTHEMES ) {
  each( @themes, {
    @theme-selector: e(@value); // sanitize theme selector
    @{theme-selector} & {
      each(@dr, #(@LESS-var, @property-name) {
		@property-value: extract( @LESS-var, @key); // extract value for respective theme

		// output each variant with the globally specified selector conditions
	    @{property-name}: @property-value;	
	  })
    }
  })
}

// usage
@variable-1: red, blue, green;
@variable-2: white, black, grey;
@variable-3: 0.5em, 0.75em, 1em;
.example {
	.mapByTheme({
      --color: @variable-1;
      --background: @variable-2;
      padding: @variable-3;
    });
	color: var(--color);
	background: var(--background);
}

produces this output:

.example {
  --color: red;
  --background: white;
  padding: 0.5em;
  color: var(--color);
  background: var(--background);
}
.theme-primary .example {
  --color: blue;
  --background: black;
  padding: 0.75em;
}
.theme-secondary .example {
  --color: green;
  --background: grey;
  padding: 1em;
}

[krsdcbl]

Thanks, that does work & I've been considering wrapping it into a mixin taking a list

I ended up deciding against this workflow. It does resolve the issue of grouping selectors for settings I'd map all in the same place, yet I casually need to map these variables at different points in my styles, within other mixins, or behind certain guards/conditions - regardless of them resulting in the same selector chains or not.

While it could be adapted to serve all these cases, It would likely require quite verbose mixin code that explicitely handles all special cases, leading to my tooling becoming inflexible, harder to maintain, likely prematurely abstracted and possibly also impacting build performance.

So I came to the conclusion that if LESS can't support selector merging internally, I might be better off keeping my mixins as pure as possible & handle the selector matching & merging in some pipeline after the build step, thus raising the question in this discussion :)