When I first started working for FlowPress I was told we were moving towards using a component based coding standard and was referenced to check out RSCSS.
I used the RSCSS documentation as more of a guideline. Along the way I discovered some issues in developing more complex systems. I’ll go over the basics of RSCSS but you should definitely check out their documentation. It’s not updated much lately, but I think it lays more of a ground work to grow you or your team’s own methods and implementation.
Components
In theory you should be able to break a website’s HTML down into individual Components. What I found is it’s really not that simple. For starters, you need Layouts. You could call a Layout a Component to keep within a strict naming convention but it just doesn’t make sense once you start really fleshing out a page. We will get back to this later.
RSCSS pushes for class names of a certain style. For Components you need to have the name of your Component followed by a hyphen followed by what it is:
- submit-button
- herobanner-image
- footermenu-list
… and so on.
Then you have what are called Elements. These are individual pieces that build up a Component. For example, inside footermenu-list you will have your <li> elements, inside those you will probably have some anchor tags, spans, icons and more. These have no spaces or hyphens in their class name but can be multiple words. Look at this example html:
Here you see the footermenu-list component made up of its elements listitems and links. Take note of the -active class, this is what RSCSS refers to as a variation. You can have variations at the component or element level.
Styling
RSCSS should be done using SASS. The mark up is very important as this standard is, in my opinion, primarily based on readability.
Let’s style the above HTML then dissect it a bit.
This code would go into its own css file titled footermenu-list.scss. A big part of the code readability is that components are separated into their own css file so no file you open will be much bigger than 50-100 lines. If they start getting much bigger you need to reconsider if it should be broken down into multiple components.
I’m a huge fan of this. Beyond code organization it helps organize your thoughts as a developer around the structure of your project. And the style code is incredibly readable and relatable to its counterparts in your HTML.
The Issues
Naming Organization
The first issue that really stood out to me was the naming convention. If I could go back to my projects and redo them over, I’d have named all my components and their files differently. Let’s take some example components of the same type.
- admin-card
- member-card
- postoptions-card
These are three different “card” Components. RSCSS like’s to use this convention for boxes that have some details and options and can float around different layouts responsively and with ease.
When looking a bigger list of different kinds of components it bugs me they are not next to each other. Being alphabetical admin-card could be next to author-header instead of the other cards.
Personally, I’d name components with the component type first. It would be more like:
- card-admin
- card-member
- card-postoptions
- header-author
- header-home
- header-single
Note: Components should never have more than one hyphen, combine words without spaces.
Complex Components
Recently working on a website built around BuddyPress but with extremely complex custom extensions, I found myself having trouble breaking down components. The design specs showed a core, round button with a font-awesome icon throughout the design. It had many variations though.
This is just the tip of the iceberg. But, In my mind, this button was a component so I created one called round-action. It seemed to me the variations would only be color, icon (yes/no/left/right), background.
But then it turns out that padding/margins need to be different depending on where it’s placed, what icon is used and how to size it. Widths needed to be auto or fixed. Some had crazy gradient hover states and others had no hover state. Some floated, some were to be block elements. Then we get into mobile handling and it was getting pretty intense.
Soon enough I had a MASSIVE sass file for round-action and no idea how I should split it up. At the end of the day I believe it’s still far more organized than if I had not used the component based system, but I know there has to be a way to improve it.
Layouts
I like bootstrapping my grids. In combination with something like using RSCSS standards this can be an issue for multiple reasons.
I did a LOT of extending. I’d have some rows in a card then columns in that and you might see:
.authortitle { @extend .row } then inside that
.authorname { @extend .col-xs-9 } and .metaicons { @extend .col-xs-3 }
There was a ton of this going on and I look back and can’t decide whether I like this or if I’d prefered to have just used the bootstrap classes on my elements. The code looks messy in the css though in the HTML it looks really nice with the actual component element names and not bootstrap class names.
Combining with PHP & JS
One of my favorite results from using this methodology was I found myself naming my php files based on components. It helped me split up classes really nice.
With JavaScript we were using the data attribute as selectors and the attribute was named after the component. So if I had a card that needed some JS functionality it might look like:
<div class=”accordion-card” data-js-accordion-card>
Then I’d have an accordion-card.js file that handled all of its functionality. Again, the organization was fantastic.
Conclusion
I highly recommend this approach to full stack development, not just css. But I also encourage getting creative and not letting it be the law of the land. There’s times it just won’t make sense to stick to this 100% and you should allow yourself to think critically and solve problems how you feel best.
Overall I have to say that Component based frameworking is awesome and improved my coding skills dramatically.
Options 2. – Efficient [ 20HR ]
– event calendar will have contractor/commercial/homeowner splitout
