Component-based what now?
official definition
-> my current approach <-
Slide 5
Slide 5 text
We’re not designing
pages, we’re designing
systems of components.
— Stephen Hay
Slide 6
Slide 6 text
What is a Component?
Components let you split the UI into
independent, reusable pieces, and think
about each piece in isolation.1
1 https://reactjs.org/docs/components-and-props.html
Slide 7
Slide 7 text
Component-based CSS pros
→ reusable
→ more maintainable
→ more comprehensible in the markup
→ easier to refactor
→ plays nicely with the component-based web
CSS component !== Website Component
Not every CSS component mirrors
a component in the markup.
Slide 14
Slide 14 text
Why? Separation of concerns does not
really work with CSS.
I'm Mirjam and I'm a cat AND dog person!
I'm Mirjam and I'm a cat AND dog person!
Slide 15
Slide 15 text
My current approach for seperation
Basic component
general styles like: font styles, colors, variables
Utility component
repeating styles that can be used universally
Counterpart component
counterpart to our website component
Slide 16
Slide 16 text
Characteristics Basic component
They are like a CD Styleguide.
They'll tell you how your brand
looks and behaves.
Slide 17
Slide 17 text
Characteristics Utility components
They help you with all the things
you would write over and over again.
They'll support you
- and your team! -
with a consistent style.
Slide 18
Slide 18 text
Characteristics Counterpart component
They determine the rules how a specific website
component has to look like. This component style
will work in every place of the markup.
Slide 19
Slide 19 text
Rules
Slide 20
Slide 20 text
Naming consistent and clear
→ mirror website component name
→ use them for scoping
→ use speaking class names
→ don't generate unexpected results (side effects)
Slide 21
Slide 21 text
Naming approach - components
.ComponentOne { // .component-one
color: pink;
.ComponentOne-logo {
height: 120px;
}
//alternativ
&-logo {
height: 120px;
}
}
// the scoping adds a bit of safety
Slide 22
Slide 22 text
Naming approach - components
More important than
PascalCase || use-hyphens || i-like__bem:
Be consistent!
Never add styles based on location
.ComponentTwo {
div {
.d-flex {
background-color: red;
}
}
}
// ҵ(`O´)҈
Slide 30
Slide 30 text
Create independent website components
Counterpart components should only contain styles
that define their unique appearance. They're
independent from their environment. You should be
able to put them anywhere in the markup without
changing their style.
Slide 31
Slide 31 text
#LifeProTips
Slide 32
Slide 32 text
My #LPT so far (Part 1)
→ don't write CSS on the side, think about an useful
architecture
→ plan your CD styleguide carefully
→ use and adapt the styleguide
→ commit to and write down naming rules
Slide 33
Slide 33 text
My #LPT so far (Part 2)
→ refactor early and often - we all know CSS grows
rampart if you don't look at it for, like, 5 minutes
→ use your basic and utility components generously
→ unify rules and styles when possible - there's
seldom need for margin: 13px and margin: 14px in
the same view
→ pls don't use pixel
Slide 34
Slide 34 text
My #LPT so far (Part 3)
→ if you write similar styles the third time, think
about creating utility components
→ if you add the third variation of a style to a
dynamic website component, think about creating
a new one
Slide 35
Slide 35 text
Let's look at some examples!
Slide 36
Slide 36 text
And that's it!
Feel free to contact me with questions! My approach
is still work in progress so I'm very happy about
feedback when you give it a try.
Twitter: @mirjam_diala
Github: programmiri
Slide 37
Slide 37 text
Further reading links
→ Airbnb CSS styleguide
→ OOCSS
→ BEM
→ CCSS
→ SUIT CSS naming conventions
→ Separation of oncerns