Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Think components. March 2017

Think components. March 2017

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.

Ivan Babak

March 21, 2017
Tweet

More Decks by Ivan Babak

Other Decks in Programming

Transcript

  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. • 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.
  4. What is a ‘component’? A component is a piece of

    software responsible for a single thing, serving a single purpose.
  5. 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.
  6. 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.
  7. 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.
  8. The name and the inputs are most important. Do not

    hesitate to make long, descriptive names of components and their inputs.
  9. 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.
  10. 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.
  11. `style` prop: 253 optional inputs. Do not increase the parameter

    space of your components by a close-to-infinite number of combinations of values.