As of today we’ve been using our ChildValidator in production for close to a year. Although some new engineers feel restricted when using components that have childTypes defined, over time they’ve realized the benefits and how it enables us to create a consistent feel across our product while at the same time increasing engineering efficiency by preventing misuse of components.

We’ve had a similar conversations with UX — by restricting how engineers can use components we are in essence restricting the designs that UX can explore. The key point is that these restrictions come from UX. They have the power to restrict (or expand) how we use components by the way they visually and interactively design them. This forces UX to dig deep when determining those constraints. The more defined the constraints are up front the higher the velocity of both UX and engineering is when it comes to high fidelity mockups and implementing new pages. At the same time, the implementation cost of change goes down while the mental cost of change goes up. There is a forcing function to think about how an underlying component change affects all pages

There are still plenty of improvements to be made — add generic types to give more power to the results from matchChildren so you can make few assumptions in your render functions, remove all any uses from the library, support exact custom counts, and handle non-React children such as functions. You can find react-child-validator on

We’re very excited for the day when TypeScript supports validation at compile time but until then we’ll continue extending our ChildValidator to support new use cases as our Style Guide continues to grow.

* we spent a significant amount of energy debating Flow vs TypeScript in summer 2017. We will have a future blog post that goes into why we went with TypeScript.