Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variable overwriting uncertainty? #2141

Closed
michaelpelletier opened this issue Sep 16, 2016 · 1 comment
Closed

Variable overwriting uncertainty? #2141

michaelpelletier opened this issue Sep 16, 2016 · 1 comment

Comments

@michaelpelletier
Copy link

michaelpelletier commented Sep 16, 2016

Hi there,

I'm encountering what I suspect is an issue with managing variables across projects. For some background, what I am doing is moving some of our static images to an external service. Our "Base" styling is available as a public repository, so what I'm doing is changing our image paths for background-image to be a variable, enabling the base styling to still work with a default setting, while also allowing for path changes within our actual app.

So, I have a default-settings file that includes variable declarations as part of our brec-base styling project (https://github.com/vecnatechnologies/brec-base). The variable in question is $staticImageUrl and is used in the modules/_forms.scss file.

This brec-base project is then installed via node's package.json, and is included in my app scss files through an @import. The app then includes a new overwrite-settings.scss file, that replaces variable definitions within the original default-settings file with app-specific values.

So, my page's scss begins like this at current, essentially importing Brec's defaults, and then overriding as necessary.

@import 'brec';
@debug 'Brec Imported';
@debug '#{$staticImageUrl}';
@import '../overwrite-settings';
@debug 'Global Overrides Imported';
@debug '#{$staticImageUrl}';

The variable is set exactly as I would expect it to be at each of those debug statements. When the brec-base repo is imported, the variable is set to ../img/, and then when the settings overwrite is pulled in, it displays the Url of my new image service.

The problem is this: I declare in brec-base that .cc-icon has a background-image based on the variable, $staticImageUrl, and even though the new app displays that the variable has updated (as I would expect), because I am not redeclaring that property in the new app, it doesn't appear to update the property itself.

Eg: If I log $staticImageUrl within the declaration of the class in my new app, it will be correct, but won't be updated.

.cc-icon {
  @debug: $staticImageUrl;
}

The overwrite will display correctly, but will not actually be used.
It will update correctly if I do this, and essentially redefine it within the new project:

.cc-icon {
  background-image: url(#{$staticImageUrl}#{$staticImageCC});
}

That "works" but it feels like kind of a hacky workaround for something that variables should already cover. If the SCSS was compiled into css before redefining the variable, I'd expect it to be unavailable. If on the other hand, it hasn't been (which is what it seems like), then shouldn't the change in variable value be picked up?

@nex3
Copy link
Contributor

nex3 commented Dec 11, 2016

Sorry to leave this unanswered for so long!

Sass is an imperative language, which means that each line of a Sass stylesheet has an effect (in terms of generated CSS) as soon as it's executed. So when you write a style rule that refers to a variable, it uses the variable's value at that point in time. This is part of the language—it allows us to have language features like @if and @each.

My recommendation when you want to lazily configure your styles is to define them in a mixin rather than directly in your stylesheets. So in brec.scss, you'd write:

$staticImageUrl: "../img/";

@mixin brec {
  // ...
  .cc-icon {
    background-image: url($staticImageUrl);
  }
}

and then your app would look like:

@import 'brec';
@import '../overwrite-settings';

@include brec;
@nex3 nex3 closed this as completed Dec 11, 2016
arelia pushed a commit to cb-talent-development/employer-style-base that referenced this issue Jan 4, 2017
Per sass/sass#2141 making tooltip a class means that class uses the z-index value the class has at the time it is declared, not the value that is assigned to the variable elsewhere
arelia pushed a commit to cb-talent-development/employer-style-base that referenced this issue Jan 4, 2017
Per sass/sass#2141 making tooltip a class means that class uses the z-index value the class has at the time it is declared, not the value that is assigned to the variable elsewhere
arelia pushed a commit to cb-talent-development/employer-style-base that referenced this issue Jan 4, 2017
Per sass/sass#2141 making tooltip a class means that class uses the z-index value the class has at the time it is declared, not the value that is assigned to the variable elsewhere
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants