Introduction What does it mean for a React team to be effective? Productive? Happy? Impactful? Since moving back into management after a several year hiatus, this has been on my mind a lot. I’ve begun to collect my thoughts into this post. Many of the ideas apply to projects of any kind, but some of the advice I’ll give will be tailored specifically to React projects and teams. Many of the ideas here build off of this earlier article “Good Software from the Software Engineer’s Perspective” where I analyze the things that make an Application “good”.

What does it mean for a software application to be good? Here’s my ranked ordered list of “good software” attributes: Solution: Provides a service or solves a problem, and does it well Design: Cohesive, intuitive interface Quality: Minimal bugs and defects; good performance Delivery: Continual, helpful updates Solution and Design: What we don’t control The Solution and Design are the most visible and obvious parts of “good software”, and at the end of the day, if they’re good enough, they can make up for all the following things to a shocking degree.

Introduction A few upsides come with adopting an opinionated framework like Ruby on Rails. One of them is having a clear pattern to the layout of a project’s source code directories and guidance on where specific code should live. This reduces the friction of creating new code modules and provides guideposts for navigating the code base. Human brains like patterns, and organizing your code into clear patterns helps developers find their way; both the newly onboarding devs and the grisled veteran devs.

Originally published on the Test Double blog here In discussions of React application architecture, React Context is often brought up as a way to implement “State Management” yourself. Some really great blog posts exist that provide techniques for implementing that exact thing like “Application State Management with React” by Kent C. Dodds. This technique can be useful for specific, one-off cases but less so for an entire application architecture. An article by Mark Erikson, maintainer of Redux, titled “Why React Context is Not a “State Management” Tool (and Why It Doesn’t Replace Redux)" provides some excellent arguments and marshalls other great articles as reference.

Originally posted on the Test Double blog here As a consultant who has worked with React since 2014, I have been fortunate to see and work with many dozens of production React codebases. In that time, I’ve noticed many patterns of use (and pain) that crop up even between very different applications. I also, regularly, get asked about the React ecosystem more generally and what things I’m excited for (or dreading).

Originally posted on the Test Double blog here Introduction A common situation when writing React components is needing to render a particular component only under certain conditions. There are many ways to accomplish this, but the route you take often has nuanced implications or differing utility based on the current state of the code/component/system. Let us consider the case of a component that requires some prop data to render. The following are two, general tactics for handling missing prop data:

Originally posted on the Test Double blog here Introduction React is an amazing library. Over the last 5 years it has transformed the landscape of frontend development and spawned an incredible ecosystem of tools, libraries, and patterns. Over that time, React has changed quite a bit. As React has evolved, so too have our applications, tools, and approaches. This year (2019), React went through one of its biggest changes with React v16.