Build A Strong Sass Architecture: Part 2
In part 1 of this series we looked at a few of the most popular CSS methodologies to date. These CSS methodologies have shaped the way that many of us write and approach CSS, and for good reason. They create structures and patterns for how we should develop. While looking at each methodology I noted some of the principles within. The reason that I called these out was because I believe they relate to what should be present in a strong Sass architecture. Principles are paramount in creating a strong Sass architecture. If developers do not build with these in mind, they tend to construct things that are not scalable, DRY, or unified. In the end I grouped the key findings together into a list:
- Define clear coding methods
- Develop with patterns in mind
- Utilize name spacing
- Create a sense of hierarchy
- Create naming conventions that make sense
- Account for states and themes
- Abstract patterns from layout
- Account for responsive
Applying Principles in Theory
"Well building hath three conditions: firmness, commodity and delight" - Vitruvius
In this article, part 2 of the 3 part series, I will expand on how these principles theoretically relate to a strong architecture. I think it is important to start off saying that I do not have all the answers that will best fit you and your team. At the end of the day I do not believe there is a one size fits all; rather, my goal is to discuss the key components and principles that are present within a strong Sass architecture.
I think this point is made clear when looking at a physical architecture. For example, if you and I were to buy a house, we might very well want two very different things. You might want a mansion, while I may want a city loft. While we are looking for different things, I can guarantee that there are principles to the architecture that we both would want in these homes. We would both probably want to live somewhere that is:
- Solid and sturdy
- Useful and pleasing
This is not a new concept. Vitruvius, the author of the Roman treatise on architecture "De Architecura" declared this stating, "Well building hath three conditions: firmness, commodity and delight". In other words, good architecture has particular components. They should be solid and sturdy, and useful and pleasing. In the same way that these core components lay the foundation of a strong physical architecture, they are also the foundation of a strong Sass architecture. Interestingly enough, these components are curated in the foundation as we apply the principles that we identified earlier.
Let us look out how these connect by categorizing the principles in relation to the components.
Solid and Sturdy
By applying the principles listed below we are able to create an architecture that keeps things simple and creates a structure that is solid and sturdy. Within each principle we will look how it does just that:
- Develop with patterns in mind- By applying this principle, we ensure that our architecture is solid and sturdy by keeping things as simple as possible. This is done by breaking our code into small chunks that live independently of one another.
- Abstract patterns from layout - We must acknowledge the difference between patterns and layout. It is like comparing a door (pattern) to a room (layout). You can have the same door among many different layouts. In theory you can also take a door from one room, and put it into another. There is a clear difference between the two things. We must do the same when tackling patterns and layout: separate them. This allows us to create a sense of structure that is strong and sturdy.
- Create a sense of hierarchy - This creates structure within our architecture to give clear direction to where things should live. Without this, our Sass architecture can begin to feel flimsy and hard to understand.
- Account for states and themes - This goes hand-in-hand with creating a sense of hierarchy. By accounting for states and themes, and not grouping them together with components, we begin to create a sense of separation and structure.
- Account for responsive - If we are going to apply responsive principles to our design, we must account for them in our architecture. If we were to just sprinkle this into our Sass, we can quickly create a mess. By being mindful and strategic about how we approach responsive, in our markup, we add to the support and solidity of our architecture.
Useful and Pleasing
Let us face it, these two things go together like two peas in a pod. The more useful your architecture is, the more pleasing it is. We can best achieve these by setting up some guidelines that our architecture should adhere to. By setting up such guidelines we create consistency and unity within our code base. We will look at the practicalities of documenting these guidelines in part 3 of this series, but for now lets look at how these principles help us achieve just that:
- Develop with patterns in mind - Not only does this principal help us create a solid and sturdy architecture, it also helps us create a useful and pleasing one. Again this goes back to the simplicity factor. By breaking down our code into bite size pieces, this increases the readability of our code base.
- Create a sense of hierarchy - Just like developing with patterns in mind, creating a sense of hierarchy plays into both components of a building a strong architecture. By building a sense of hierarchy we create a sense of separation between all the parts of our codebase which makes it easier to find what we are looking for.
- Define clear coding methods - We must set clear coding methods/guidelines within our code to tell how the code should be written. This contributes to a strong Sass architecture because, just as road signs show us what to do on a road, they gives us clear directions on how we should our work. This is super useful and makes it a lot easier to on board other developers onto the project.
- Utilize name spacing - This allows us to create a sense of separation in our code base, as well as it gives us clear indicators in the DOM to distinguish between our codebase and third party code bases. This gives us direction on how to find the styles relating to the HTML block we are working on. Who doesn’t like a bit of direction?
- Create naming conventions that make sense - We must name things well. I know this is one of the hardest things to do, but spending the time to come up with naming conventions that the entire team and new developers will understand, will save yourself more time than you know. We can accomplish this by tying our names to core programming definitions. We will look at an example of how this practically plays out in part 3 of this series.
Hopefully this gives you a high overview of how we can apply these principals and components theoretically to our Sass architecture to make it stronger. In part 3 we will look at how we might practically apply these concepts to a Sass architecture.
You will not want to miss that!