Variables about ui_alchemy-rails HOT 9 CLOSED

Notation:
A note on the notation, I have no references to really back this up but I am a big fan of mixing underscores and dashes to separate the canonical name from the property. For example,

login_container-height
login_container-box-shadow
login_container-width

However, I have always been torn between:

login_container-top-margin
vs.
login_container-margin-top

Variable Storage Location
I have tended towards liking a single point of reference for variables al la _vars.scss. However, I can also see the argument for including variables logically with the component (i.e. login.scss variables live in the login.scss file). But, once you start using cross component variables you get a disconnect on where entities live. I don't think requiring the use of _vars.scss by every file is bad though. Similar to requiring an interface I suppose since you have the freedom to define those variables and interface yourself if you wanted.

from ui_alchemy-rails.

Notation:

As for me, I would vote to use just underscore. It is clear and unified and you don't have to think, if there should be underscore or dash (or what used somebody else). I understand your point of mixing those two - I have used this approach on one project as well - but I came back to simple underscoring, because it is really confusing mixing those two.

Variable storage:

I also have used single storage for variables in some projects, but when it's getting bigger, it's more and more messy. In one file you have shared variables, specific ones and when you want to change component related variable (which i used just for that component) you have to search for it in some other file. I am for keeping shared variables, which are used across components, in _vars.scss. If there are local variables used only in that component, I would keep them just in related component's scss. For documentation, I would just write in the beginning of component scss which variables/colors/mixins are used and from which file they are inherited, so everybody knows where to find which variable.

IE hacks:

I vote for keeping it in the same component's scss.

Responsive:

I vote for keeping it in the same component's scss.

from ui_alchemy-rails.

@jcoufal as for the variables, I think it is simple enough to find where the variable comes from, because it should be always set either directly in the given file or in _vars.scss (correct me if I am wrong), adding the variables documentation at the begining of file brings responsibility to maintain it.

from ui_alchemy-rails.

IE hacks:

I vote for keeping it in the same component's scss.

+1

it would be very annoying reading a scss file full of nothing but +ms-filters and guessing what other factors are at play.

Responsive:

I vote for keeping it in the same component's scss.

• 1
  responsive helper classes ( like .hidden-handheld etc )should go in the helpers scss and not a separate responsive scss.

If a special primary button has to go from display:inline-block; to display: block; width: 100%; when responding, it has to be in the buttons scss and nowhere else.

—
Reply to this email directly or view it on GitHub.

from ui_alchemy-rails.

@jtomasek as for variables doc - ok, agree

from ui_alchemy-rails.

Two things.

First, sounds like we can agree to the following rule:

Variables should be placed in one of two places and nowhere else. Cross component variables should live in partials/_vars.scss while component specific variables should live at the top of the component's scss file.

I would like to take the above and also add the stipulation: ALL variables should be !default in order to allow easy customization by a parent project

Second, while I am a fan of the components feeling stand-alone, I get this wonky feeling whenever I start to see large SCSS files with sections that are unclear where those sections live. For example, do we define that an SCSS component file should go:

1. Imports
2. Variables
3. SCSS code
4. Mixins
5. Responsive
6. IE Hacks

Part of me feels it might be cleaner to organize more like:

components/_forms.scss
components/ie/_forms_ie.scss
components/responsive/_forms_responsive.scss

from ui_alchemy-rails.

@ehelms About the structure - I would move mixins after variables (to the top of document) - because those two are similar.

Regarding splitting into more files. +1... Yes, It might work from my point of view.

from ui_alchemy-rails.

Is this basically closed?

from ui_alchemy-rails.

It was, but if there are more discussions (and right now there are), we can re-open.

from ui_alchemy-rails.