-
Notifications
You must be signed in to change notification settings - Fork 19
Frontend Things to Avoid
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.
// do this
const StatelessComponent = () => (
<div></div>
);
// not this
class StatefulComponent extends React.Component {
getStatelessComponent = () => (
<div></div>
)
}
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
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.
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.