Bulletproof Components (Part 1): Front End Checklist

Index

"All the world's a Sitecore, and we are merely components." - William Shakespeare

This series of posts is a reflection on years of component development. Years of painful lessons have been condensed down into simple checklists for you to run through as you develop.

These posts seek to:

• Improve the requirements gathering and design phases
• Standardize the component development approach
• Reduce low value churn during the QA process
• Speed up development
• Reduce costs for all project stakeholders
• Increase customer satisfaction thanks to a simpler content authoring experience with fewer issues and quirks
• Foster a culture of thoughtfulness and critical thinking

Starting with the end in mind, the front end design and implementation is our major guide in how components are built. Front end architecture should ideally be "back end agnostic". Thus much of the front end checklist items are widely applicable to any web project; Sitecore or not.

Your implementation may vary. These checklist items can apply to any view file containing HTML with some form of logic such as .cshtml or .twig.

• Does the file name and path of the file match the requirements?
• Is hardcoded text that is visible to the user (ex. "Open Navigation") accessible by the back end development team?
  • Any visible text on a website should allow for content authors to modify or translate it.
• Do your links display the appropriate attributes such as target, rel, and title?
• Does your component meet your SEO requirements?
  • Are your heading elements properly categorized (h1, h2, h3, etc)?
  • There should typically only be one <h1> tag per page (although there are cases in which it is appropriate to have more than one).
• If your component has columns, did you consider how the length of content in each column will affect the height of the columns and how they may wrap on different screen sizes?
• Do your images display their alt text?

• Are your rich text content areas wrapped in a block level element like a <div>?
  • Wrapping a rich text field in a <p> tag won't work because there are limitations as to which elements that tag can contain.
• Do you have a standardized wrapper class on your wrapper element?
  • You will likely have many rich text fields contained within many components.
• If your component has different color treatments (background colors, etc.), do your <a> tags react accordingly?
  • Are the colors high contrast enough?
  • What about hover states?
• Do images inserted into the field display as expected?
  • What about small images?
  • Large images?
• Did you account for the possibility that iframes or video embeds will be inserted?
  • Are they responsive?
• Did you test for cases in which words may overflow and/or wrap due to their length?

• Do you have any hardcoded text that gets displayed?

  • Does the back end team have access to it such that the text can be translated or changed in the CMS?
  • One good place to store these words is as data attributes on elements in the view rather than inside of the JS itself.

• Do multiple instances of the component on the same page affect each other?

  • For example, do your event listeners "unexpectedly" affect other instances of the component on a page?
  • Scope should be determined based on where an action took place, such as the target of click events.
  • Alternatively, unique IDs can be applied to the top level wrapper element of each instance of the component.

• Would your JS be more modular and scalable by incorporating event firing and event listening?

• Have you made an effort to limit any JS errors to this instance of the component?

  • In other words, if the JS of your component experiences an unhandled error, will it break other areas of the page, or worse yet, the entire page?
  • This is especially crucial for websites that have one monolithic minified JS file.

• Are your classes, selectors, IDs, etc, stored in a central location?

  • The location would typically be at the top of the file, and would be customizable via module constructors that have default options, but allow for customization if future implementations of the component require different selectors.

• Do you have any code that should be removed?

  • Comments?
  • Console logs?
  • Alert boxes?

• Did you leverage variables?
• Do your line height properties use numbers such as "1.2"?
  • Other values such as px or % may cause unexpected behavior.
• Does your CSS handle different sized images (small and large)?
• Are your media queries in a consistent order?
• Do you have any comments that could be removed in favor of more descriptive selectors?

Front end is complete! The next post will cover the back end, or the "Sitecoreization" phase as developers like to put it.