As a very early adopter of React—selecting it after finding angular’s abstractions to be poor, particularly the flow of data and the use of essentially string-based templates—I have developed applications of all sizes and levels of complexity using React for many years now. As a consequence of having followed the library and community through so many prior phases and minor revolutions (eg. moving from various Flux implementations to the abstraction of redux when it first arrived on the scene), I possess a depth of understanding of the library as well as a wealth of knowledge of patterns and practices for large applications. A side note, reflecting my preferences: one popular approach to state management that I tend to reject on principle is mobx, my opposition to which once led to a protracted debate and fierce whiteboarding over the centrality of immutable data flow to React’s architecture. Today, I tend to prefer smaller compositional reducers using the withReducer hook, where possible.

Beyond the popular state management frameworks, my work with GraphQL has often (although not always) been paired closely with React, thanks to the Apollo tools that so definitively bested Facebook’s official relay offerings. I have closely paired the graph-based nature of that technology with the hiearchical layout and encapsulation of components, happily employing fragments at the component level alongside other compositional techniques for clean abstractions.

Over time, I have migrated nearly all of my React work into Typescript, which of course greatly improves the integrity of applications and maintainability of larger codebases. And with the relatively recent move to hooks—an abstraction that pairs so well with functional thinking and the clean flow of state & side effects—I find the workflow in React to be unparalleled in the UI space. The only major criticism it leaves me with is a sense that I wish it weren’t so successful as to have crowded out my interest in using its alternatives for projects, since in most technical areas I consciously devote efforts to avoiding a totalizing lock-in under a single library or approach.

As for testing, I have orchestrated detailed tests at all levels of React projects, including component-level unit tests, data fetching or graphql simulations, integration tests, etcetera. The testable nature of components is what I consider to be one of the leading reasons to adopt React as a UI layer. I have used elm in a few limited cases, and very briefly have explored what may be the better compromise—reason / reason-react—but so far those have not made up a major component of any of my larger projects.

A couple of my more minor contributions to open source in the React space, that nontheless typically recieve 10k a month or more downloads, are slate-deep-table, which offers perhaps the only well-structured “deep” table (meaning, cells that can contain other block-like content all the way down) implementations for a schema-controlled editor in the class of slate, and react-super-responsive-table, which my junior hire at UA (now employed at NearForm) smartly cleaned up and published from a component I built for our internal use.