Frontend Things to Avoid - department-of-veterans-affairs/caseflow GitHub Wiki

Avoid Using Higher Order Components (HOCs)

Higher order components obscure application logic and data and can make components harder to reason about. Consider refactoring components to take additional props rather than wrapping components to add new props / functionality.

Avoid Defining Components via Class Methods

// do this
const StatelessComponent = () => (
  <div></div>
);

// not this
class StatefulComponent extends React.Component {
  getStatelessComponent = () => (
    <div></div>
  )
}

Prefer Concise Syntax

If needing to access a deeply-nested value where you can't guarantee object structure, use the optional chaining operator.

Example:

// Wrong — this might throw an error if obj1 or prop1 are null or undefined
const myVal1 = obj1.prop1.deeplyNestedVal;

// Wrong — this is excessively verbose
const myVal2 = obj1 && obj1.prop1 && obj1.prop1.deeplyNestedVal

// Right — hooray for new features!
const myVal3 = obj1?.prop1?.deeplyNestedVal

Avoid Using Glamor for CSS Styles

In the past, many Caseflow components used Glamor to apply styling. This is a CSS-in-JS solution that allows for styles to be applied to components without the chance of conflicting class names. While it currently still works, Glamor largely has not had an update for 3+ years, and one can better accomplish the goal of conflict-free component-specific styles by using CSS Modules.

New Date()

When creating a date object from a date string that is passed from the backend, avoid using new Date(dateString). Instead, use parseISO(dateString).
Using new Date(dateString) could introduce an off by one error due to timezone issues. We store dates on the backend in UTC, but new Date(dateString) will interpret that as UTC midnight in local time. For the Western Hemisphere, that will always be off by one. If you need to display the date object as a string, use formatISO(dateObject, { representation: 'date' }); It is safest to pass information with full time information (including TZ or offset), as Rails will properly store it as the correct UTC date.

⚠️ **GitHub.com Fallback** ⚠️