Atomic Migration Strategy for Web Teams

Chapter 3. Atomic Design: A Tool for Migration

In the previous chapters, we’ve discussed reasons for when it makes sense to rewrite an application and covered how to decide between a synchronous or asynchronous rewrite strategy. Now we’ll delve more deeply into the principles of atomic design to show how the concepts of building modularly can be used successfully in both synchronous and asynchronous rewrites.

Atomic design shifts focus from designing web pages to thinking in terms of component systems. It breaks up complex interfaces into discrete pieces that can be focused on one at a time, used in a number of different contexts, and put together in growing orders of complexity.

Build Complex Systems out of Simple Parts

As you might recall from the Preface, in atomic design complexity is created by stitching together simple components, much like Lego pieces. Using simple pieces that can be combined to build more complex interfaces is a powerful tool to apply in software engineering. It allows an engineer to reason about larger groups of complex systems, without needing to hold entire context of all the subcomponents in working memory.

Atoms

Atoms are the simplest components in atomic design. They are the basic building blocks that are pieced together to form more complex components (see Example 3-1). Atoms are designed to be used in a number of different contexts and make no assumptions about where the state came from.

Example 3-1. A Button Atom with configuration perameters ...