How to architect and build software components.
Software Architect, Frontend Software Engineer
Examples assume familiarity with React.
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.
Every software engineer makes
architectural decisions daily.
Small or big. Often without realizing that.
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
What is a ‘component’?
A component is
a piece of software
responsible for a single thing,
serving a single purpose.
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.
How to architect a component?
Like a function.
React components are functions, too.
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.
How to architect a component. Case study: Tooltip.
● 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
3. Name `AcmeDashboardTooltip`
← Context → ← Responsibility and Purpose→
● Reference UI element that will accept hover interaction.
● The tooltip content.
5. Outputs ● The React DOM element that implements the tooltip.
● Has current state: visible / hidden.
● Changes state on mouse hover interaction.
● Requires positioning independent of ‘parent’ browser
The name and the inputs
are most important.
Do not hesitate to make long, descriptive names
of components and their inputs.
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
● Making an input optional increases the parameter space.
● A good way to keep yourself from adding more inputs is to write a test suite
with every combination of their values.
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.
`style` prop: 253 optional inputs.
Do not increase the parameter space of your components
by a close-to-infinite number of combinations of values.
`className` prop: even more inputs.
CSS cascading, hover, focus, media queries, ...