A deep dive into type-checking React children and the organizational ramifications of design consistency

At ActionIQ, we aim to simplify the complexity of customer data platforms (CDP) through our enterprise grade UIs. In the last few years as the CDP space has continued to grow and mature, so has our product. As our product expanded we aimed to build a coherent and consistent experience across our platform starting from the top with our <Layout /> all the way down to a simple <Button /> . No matter where on our page you find a button, it should look and feel like an ActionIQ button.

This exploration led us to develop an internal Style Guide (see future blog post) that defines how components and elements at all levels should look and feel. The tricky question we began to ask ourselves as engineers was “How can we enforce certain relationships between elements?” If we have a <ButtonGroup /> , how do we prevent engineers from accidentally filling it up with something besides a <Button /> ?

Flow solves this in a very clean way but we’re a TypeScript shop!* When we started researching this problem and looking for solutions we found that TypeScript did not, and still does not, support typing children (see the GitHub issue for more info). So as all engineers do, we decided to implement something ourselves.