This document discusses component-driven development (CDD) and provides guidance on how to implement it. It defines CDD as building user interfaces from individual components. Key principles include: 1) Creating isolated, reusable components that are easy to test and maintain. 2) Using tools like Storybook to develop components independently before integrating them. 3) Establishing naming conventions and style guidelines to ensure consistency. The document outlines best practices for component-based workflows, such as having each task focused on one component and reviewed through a single pull request. It also notes when CDD may not be practical, such as for small projects. Overall, the document promotes CDD as a way to encourage collaboration and

1. Hello!
I am Mykola Kozhukharenko
front-end dev in Krusche & Company
I’m on Github

2. COMPONENT
driven
DEVELOPMENT
HOW-TO GUIDE

3. WHAT IS
CDD?

4. Process
of building UI from
very bottom
UP

5. IS IT NEW IN UI?

6. ATOMIC DESIGN

7. ATOMS MOLECULES

8. ORGANISM
TEMPLATE

9. - Duplicated functionality
- Block each other work
- Too many merge conflicts
- MR take too much time to be merged
- hard to find the place to start the task with
PROBLEMS TO
SOLVE:

10. WHAT IS THE
“COMPONENT”?

11. 1.isolated (from business logic and
others)
2. easy to unit-test

12. 3. look and behaves the same
throughout an app
- no side effects
- no margins
- small and clear API

13. 4. Can be combined to create
new components, pages,
modules

14. HOW-TO
RULES TOOLSand

15. TOOLS

16. UI component explorers
tool #1
as an example:

18. Process
- Build components in isolation
- Specify state and stub data from within
your component’s directory
- Register it

22. UI component explorers
- React Storybook
- React Cosmos
- Carte Blanche
- React Styleguidist
- React Bluekit
- Electrode Explorer
- Vue-play
- Ember Freestyle
- Create your own
10k ★
2k ★
1.5k ★
1.8k ★
250 ★
200 ★
600 ★
180 ★
0 ★

23. OBVIOUS ADVANTAGE
- Sandbox for creating elements
- visualization for different comp. states
- easy to setup a docs/specification

24. UNOBVIOUS:
- force to think in terms of comp
- force to create smaller comp
- force to isolate comp

25. .fill-blanks-editor
.fill-blanks-editor__node
.fill-blanks-editor__node--is-multiple
.fill-blanks-editor__node--focused
.fill-blanks-editor__word
.fill-blanks-editor__word-content
CSS: NAMING CONVENTION
Tool #2
(OOCSS, ACSS, BEM, SMACSS)

26. const styles = style({
'default': {
card: {
background: this.props.background,
boxShadow: '0 2px 4px rgba(0,0,0,.15)',
},
},
})
<div style={ styles.card } />
OR CSS IN JS?

27. idiot proof
(wiki ru, en)
❝

28. RULES

29. One task - one
component - one PR
Rule #1

30. Keep it small

31. Display all possible
states
Rule #2

32. Isolate a component
Rule #4
develop it outside normal app

33. CODE REVIEW
Rule #4
check rules #1 #2 #3

34. Developers are lazy
❝
© someone

35. TOOLS RULES
We need a balance

36. WHY CDD?
- work in parallel
- easier to review and test
- new developers starts faster
- easier to maintain
- easier to setup css regression
testing

37. FRAMEWORK
DOESN’T MATTER

38. WHY NOT CDD?
- Time consuming
- treated as auxiliary project.
- seen as a tool for devs (not
business)
- it's often created after project
started

39. - One task - one component - one PR
- isolate it using component explorer
- cover all possible states at once
- code-review: ensure rules are followed!
HOW-TO
RULES

40. - Component explorer (Storybook, etc)
- BEM/css modules/css in js
HOW-TO
TOOLS

41. When to apply?
- There are 2+ FE developers
- The project is developing
continiously

42. Thanks!
Any questions?
You can find me at
twitter @mkozhukharenko