KittyGiraudel
commented
9 years ago Hey. Allow me to give my opinion here since you asked for it.
Let me break the ice to get things started: people don't think maps are weird. It's been months if not a year since maps have been first introduced to Sass so it's safe to tell things are well set up at this point.
So the question isn't "should you be using maps ?" but "what for ?".
What is interesting with having a map (or maps), is that you can loop over it, which is obviously not possible with variables. Actually, that's the main reason why maps have been introduced to Sass in the first place: to provide a solution to variable variables.
Having an ability to loop over a map is a huge plus when you come to build a living styleguide or basically anything that comes around the project (documentation, exports, ...). It's much more convenient than having a handful of variables to move over.
Also as you said, and I fully share your opinion, maps make your code more structured. For instance, this is what our _variables.scss file looks like at work. Definitely easier to read than countless variables in my opinion.
Let me warn you against having a super map. This is indisputably a bad idea.
For starter, deep maps can be a pain to update (reading is and will always be the easy part). Updating a 2-levels map is a pain to update manually. Needless to say building a function to dynamically update a nested map is a nightmare...
Moreover, deep maps tend to be slow. Everything is relative at this point of course but very dense maps can bring some slowness to your app. I'd warn against having more than 3 or 4 nested levels, it's probably too much.
Instead, try breaking your map into several smaller items. For instance, instead of:
$foundation: (
button: (
// ...
),
carousel: (
// ...
),
dropdown: (
// ...
)
);... try something like this:
$foundation-button: ( ... );
$foundation-carousel: ( ... );
$foundation-dropdown: ( ... );Not only does it avoid having to deal with deeply nested maps, but it also allows you to move each configuration to its own relevant partial rather than storing everything in the same file (which may or may not be what you want).
Again, I think I'd advise against using a single function. Actually the name is the biggest flaw here. foundation means nothing (sorry). Pick something that actually makes sense, like map-fetch, then alias it with custom functions. Like so:
/// Helper function
/// @access private
/// @param {Map} $map - Map to parse
/// @param {Arglist} $keys - Series of keys
/// @return {*} Value at `$keys...` in `$map`
/// @todo Write input validations
@function map-fetch($map, $keys...) {
@each $key in $keys {
$map: map-get($map, $key);
}
@return $map;
}
/// Get color from palette
/// @access public
/// @param {Arglist} $kets - Series of keys
/// @return {Color}
@function color($keys...) {
@return map-fetch('color', $keys...);
}
// Usage
$foundation-colors: (
"primary": (
"light": lightgreen,
"normal": green,
"dark": darkgreen
)
);
$color: color(primary, light);Consider using f-color or foundation-color (although that's a bit long) to avoid any naming conflict. If you want to stay consistent and avoid any possible confusion, you might want to consider using get-* name (e.g. get-color()).
While multiplying frameworks isn't a good idea, using external libs can totally happen. You don't want those libs to mess with the framework, do you?
My 2 cents. If you need any more help, be sure to ask.
xzyfer
Undistraction
benfrain
gakimball
AshleyAitken
DerFrenk
viztastic
zurbrandon
Right now we're looking at which of the hot new Sass features we want to use in Foundation for Apps. We'd like to shoot for libsass compatibility so our stack can be pure JavaScript, so when we say "new features" we mostly mean "maps". Maps aren't yet a native libsass feature but there is a polyfill for them.
Currently, frameworks spill out all of their variables like this:
Maps give us an opportunity to bring more structure to our settings file, by allowing us to craft an array of settings:
Because of the confusing-ness of the
map-get()function when accessing nested maps, we'd abstract map access out to a singlefoundation()function.More complex components could separate their settings by component.
What we want to know is, does this make sense? Will users understand it? As far as how we write the components, we plan on giving users the same amount of customizability they're used to in Foundation 5. As usual our designs will be un-opinionated so you can easily overwrite them yourself.
Here are the benefits:
$foundationvariable, we're basically guaranteed to not have conflicts with other libraries. Of course, we can't namespace our mixins, but we can at least group our settings together.Here are the downsides:
Foundation.button.colororFoundation::button::coloror something like that. Since Sass is entirely functional, our accessor syntax looks a little funky.foundation(button, color). It's not a way people are used to having to access arrays. Explaining the syntax is a little easier if you break it down where the first attribute is a component, and the second attribute is a setting of that component. But there's possibility to nest more levels deep, at which point your syntax looks likefoundation(menu-bar, icon, size)or something like that.Arguably it doesn't make memorization of settings any harder. You're still going to have to look up the really specific ones. However, there are a few that people use a lot in development.
So those get slightly more obfuscatory, perhaps. It's a matter of re-training people mostly.
And as always we're going to try to balance best practices with ease-of-use for our users. If you went and asked any programmer, "would you rather list a bunch of related things as their own variables, or put them all in array?" the answer would be obvious. It makes sense to put things in arrays from a best practices perspective. That doesn't mean it's what's easiest for our users to understand necessarily.
But that's what we're trying to find out. Let us know what y'alls think!
Addendum
To expand on this slightly, we don't necessarily need to contain everything inside one
$foundationvariable. We could have separate variables for, say, component settings, global settings, breakpoints, and colors. The question is then how you access them.