-
Notifications
You must be signed in to change notification settings - Fork 3
A1: This is the number one question that we asked ourselves when applying SMURF in practice and the answer it definitely: "No, it's not always worth it". This is what the "non-modular" category is for. It takes a long time to get modularization right and if you are in doubt it makes a lot of sense to first put into "non-modular" and then graduating it into a module once you know it will live on and need to be reused. This is a fairly common practice for DRYing up code and avoids premature optimization.
On the other side of this argument, we truly believe that "clean code should live in clean files". So taking all the extra effort to modularize styles makes a lot of sense to communicate to other developers that somebody thought about this code and it's meant for reuse. If applied like that at the right place all the extra effort of modularization will pay-off very quickly.
A2: Since both constructs change or modify something about a module the question might come up on how they are different. For example, in BEM (another modular frontend approch) they would both be called "modifiers".
First of course there is the semantic difference that a state is only a temporary change to a module (triggered in some way by the user context), while a submodule is a permanent modification of a base module for certain application conexts. But in addition to that there is also the differentiation that states are tightly integrated into modules and would also be inherited and could be modified from a submodule. Submodules in contrary only share an inheritance relationship with a module.
A3: Layout classes are exclusively used to determine the positioning, width, floating of elements. Examples are .l-container, .l-sidebar, .l-main-column, .l-quarter-column, etc. They should not include any "visual styles" like color, background, etc.
A4: The design thinking behind a SMURF root module (e.g. .m-box) should always be to encapsulate the least common denominator of all its submodules. What you should avoid is a situation where you need to "subtract" styles in some submodule that were defined in the root module. You should only ever add or change styles in a submodule.
A5: We know that the notation for SMURF is very verbose and not really beautiful. The thing is that there is a trade-off between selector beauty and clarity. And SMURF simply took the road of being as clear about a selector's category, composition and responsibility as possible at the sacrifice of nice short selector names. However, the notation is definitely not the key part about SMURF/SMACSS. We believe that you can follow 80-90% of the ideas behind it with a totally different notation.