How to architect and build software components. Improve your understanding of software components and how to architect and build them. Examples assume familiarity with React.

1. Think components.
How to architect and build software components.
Ivan Babak
Software Architect, Frontend Software Engineer
Examples assume familiarity with React.
March 2017

2. Software architecture is
the structure of a software system,
the components and their properties,
and the protocols between the components.
What is ‘software architecture’?
A protocol is a system of rules of communication: how the elements talk to each other.
A structure is a set of elements: which elements belong to the system.

3. Every software engineer makes
architectural decisions daily.
Small or big. Often without realizing that.

4. Every software engineer makes architectural decisions daily.
● How to name a thing: a variable, an object field, a function, a class, a module.
○ Good architecture starts with correct naming. The name summarizes the purpose of the thing.
○ When the purpose changes, the name must change to reflect that.
● How to structure a thing: function arguments, objects, pieces of code.
● Where to put a thing: a variable, a function, a class, a module.
● How to organize the data flow in a piece of code.
○ Data flow is the path that certain pieces of data take through the program.
● How to organize the control flow in a piece of code.
○ Control flow is the path that the processor takes while executing the program.
● How to comment a piece of code.
○ Telling the reader why the code is written this way, not just what it does, helps to understand the
architecture.

5. What is a ‘component’?
A component is
a piece of software
responsible for a single thing,
serving a single purpose.

6. A component is like a function.
It has a context, a single task it performs, a name,
a set of inputs, outputs, and an internal behavior.

7. How to architect a component?
Like a function.
React components are functions, too.

8. How to architect a component? Like a function.
1. Context – what is the environment the component will live in?
2. Single responsibility and purpose.
3. Name – based on context, responsibility, purpose.
4. Inputs – the pieces of data required to fulfill the component’s responsibility.
5. Outputs – the pieces of data generated by the component.
6. Behavior, lifecycle – how the component will fulfill its responsibility.

9. How to architect a component. Case study: Tooltip.
1. Context
● React-based dashboard at a company called Acme.
● No existing tooltip.
2. Single responsibility & purpose
● Display a tooltip on mouse hover over an arbitrary UI
element.
3. Name `AcmeDashboardTooltip`
← Context → ← Responsibility and Purpose→
4. Inputs
● Reference UI element that will accept hover interaction.
● The tooltip content.
5. Outputs ● The React DOM element that implements the tooltip.
6. Behavior
● Has current state: visible / hidden.
● Changes state on mouse hover interaction.
● Requires positioning independent of ‘parent’ browser
DOM element.

10. The name and the inputs
are most important.
Do not hesitate to make long, descriptive names
of components and their inputs.

11. How to architect a component: inputs.
● Defining inputs is of utmost importance. It’s as important as the correct name.
● Understanding implicit inputs is even more important.
○ Examples: environment variables and APIs, cookies, etc.
● The fewer inputs, the better (more maintainable, future-proof, foolproof).
○ Restrict the inputs to just the essential parts of data required to fulfill the component’s
responsibility.
● Making an input optional increases the parameter space.
○ One more value to test. In JavaScript, even more than one.
● A good way to keep yourself from adding more inputs is to write a test suite
with every combination of their values.

12. How to architect a component: inputs. Examples.
● Function arguments.
● React props.
○ Can be treated as function arguments.
● React state.
● React context.
● Browser and platform environment, if accessed directly from a component.
● Cookies, storage, if accessed directly from a component.

13. `style` prop: 253 optional inputs.
Do not increase the parameter space of your components
by a close-to-infinite number of combinations of values.

14. `className` prop: even more inputs.
CSS cascading, hover, focus, media queries, ...

15. Thank you.
It’s time for a cup of coffee.