Support Nested Vary Object about sass-vary

[jaicab]

First of all, the idea behind vary is not to abstract every property, but simply do the theming part of it.

Now maps of a deeper nesting level have always been on the list. I wanted to see how people reacted to vary's current complexity before going for this feature.
What I'm worried about is scalability and flexibility. Right now, the $key in vary-get is a string so people can name the variables as they please. Introducing a system like this could be very confusing in terms of errors if somebody didn't use quotes or something, as $key would need to become a list.

They way this should work should be infinitely scalable, based on your example:

$vary-map: (
  user: (
    color:  (
       primary: red,
       secondary: blue
    ),
   background: (
      main: (
         url: 'http://...com',
         color: '#000',
         position: (
            left: '0',
            top: '10px'
         )
     ),
  ),
) !default;

With a lookup:

@include vary($create: parent) {
    background: vary-get(background main color) vary-get(background main url) vary-get(background main position top) vary-get(background main position left);
    color vary-get(color secondary);
  }

As you can see, you could access any property using a list instead of a string. Since this list can be infinitely long, the level of nesting could be infinite as well.
The other problem is the thin line between theming and complete abstraction. I don't want the map to get way more complex than it is. The idea is to keep it simple enough that you don't have to work out which value you need and go and recheck on the variables file.

I'll play with this idea.

[Undistraction]

First of all, the idea behind vary is not to abstract every property, but simply do the theming part of it.

Don't worry. I totally agree on this. Have been down that rabbit-hole before. I think the issue centres around scalability. If I'm working on a simple marketing page with a couple of fonts and a few brand colors, variables like brand-primary are sufficient. The problem arrises as a project increases in size, and through design iterations. If all my selectors reference brand-primary, what happens when one of the components changes its color-scheme but the other is still brand-primary? I now have to change the CSS, not the theme object, and surely the point of theme object is that the entire theme is encapsulated there; I should be able to change the theme-related properties of a component from the theme object.

If instead of declaring the background-color of a component as brand-primary, I use a key based on the component instead: say tab.background-color, I am now free to theme that component independently of any other component. To me this is the (potential) power of theming.

Obviously you could argue that a theme is a locked-down set of styles, and the fact that both the button background and tab background colors are inexorably linked and must always be the same colour is a part of the design decision process, but in my experience, for something like theming, flexibility is key. I guess it depends on what kind of problem you want Vary to solve; I could see it being useful on projects with only a single theme, but one that is in flux as a way of ensuring consistency and keeping theme-related properties in a single place, or in creating more finely-grained customisable themes. Of course this introduces more complexity, but power and complexity (in implementation) always seem to go hand-in-hand.

Very possibly you are right to focus on just the theming aspect, but always worth chewing these things over imho.

[jaicab]

Ok so I've been giving this more thought and may implement it as explained above. The problem is how to approach this without affecting the current setup.

Obviously the more reasonable thing to do would be to unquote the vary-get parameter and assume it's a list of keywords to access the different levels in the map. So when it's quoted, vary will understand it refers only to the first level, as the length will return 1 element.

The issue with that would be: what if you want to use strings that require quotes for some reason? So the other option is to use it like so:

vary-get(('color', 'the background', 'url'));

The other issue with this is the fact that if you give it an unquoted string with spaces Sass will understand it as a list. So if I did this:

vary-get(color primary)

It would be understood exactly like:

vary-get(('color', 'primary'))

To sum up, I don't know how to approach this without affecting flexibility directly. Is using another parameter a viable option? It would get longer though.

vary-get($go: color primary)

This approach could be interesting, moving it to default behaviour in more advanced versions if more popular than the regular approach. Thoughts?

[Undistraction]

The problem is how to approach this without affecting the current setup.

The project is still young and you are fleshing out the API. Don't be afraid to bump the version.

what if you want to use strings that require quotes for some reason?

That's a really edge case. The object keys are really equivalent to variables, so I think it's no problem applying the same restrictions.

The other issue with this is the fact that if you give it an unquoted string with spaces Sass will understand it as a list

Again, I would say this is pretty edge. I didn't even realise using a key containing spaces would compile.

Is using another parameter a viable option?

I would say this is adding complexity to a lovely simple API to cover two very edge cases. If you do want to cover them can't you use an arbitrary number of params?

@function example($path...){}

[jaicab]

I have been doing some tests and turns out vary-get will fail if it receives an unquoted string with spaces, so since it doesn't have the same behaviour as I thought the first explained approach is actually valid because it achieves both a new feature and an error by completely removing the quotes, even though it's not a great practice.

A quoted value will get you the regular old, one level map vary and an unquoted will go for the value going into the map using the keys separated by spaces. You can actually combine them nested maps and quoted strings. Check it out on SassMeister.

This feature is already available (although not properly documented) in the dev version of vary 1.2 💃

[Undistraction]

Nice work.

Forgot you can't use variable length params there as there are already subsequent params.