Front-end developer code review checklist
The checklist provides a list of questions that Pega front-end developers can ask themselves and other developers when reviewing UI changes.
The checklist is not meant to be an exhaustive list of possible questions. Rather, it is a starting point to ensure that everyone is following best practices and taking full advantage of Pega's UI features.
Sections
- Is this section using the minimum number of layouts (for example, remove layouts that wraps section includes, or layouts used only to visually group items)?
- Is this section using the latest Skin formats (for example, no deprecated formats)?
- Are layouts and sections using container headers where possible (instead of using one layout for the header and one for the body)?
- Should this section use a design template?
- If so, should it be editable at runtime?
- Does it need to be marked as a Workarea layout?
- Does the section need to be marked as a Workarea widget?
- Is this section using the latest optimized layouts and button markup?
- If the section contains a Table, can it be replaced with a Repeating Dynamic Layout?
- If not, can it at least use the Table's Optimize for mobile option?
- Can duplicate controls be combined into one control with multiple actions and when conditions?
- If duplicate layouts are using different container formats, can they be combined using a container format property reference?
- Are all guardrail warnings justified?
Harnesses
- If the harness has CSS files attached to it, should they be moved to the Skin level?
- If the harness has JavaScript files attached to it, should they be moved to a script bundle and attached to the portal harness instead?
Design templates
- What are the template's name and region names?
- Does the template's description explain how to use it?
- Does the template have the proper icon?
- Does the template have any visual styling or container formats in it (for example, it should only determine how regions are laid out)?
CSS
- Can the overrides be replaced with existing helper classes?
- Can the overrides be replaced with an existing Skin format?
- Should the overrides be converted into a new Skin format (especially if they're used in multiple places)?
- Are the overrides using mixin references whenever possible?
- Can we replace the !important flag with more specific selectors?
- If not, are there comments explaining why it is necessary?
- If the overrides are using floats or absolute positioning, can they be replaced with flexbox based styles?
- Do the overrides account for optimized layouts (for example, No references to .layout or .layout-body)?
- Do new helper class names follow naming conventions?
- Are new global helper classes specific enough to work in all cases?
- Are helper classes properly documented so they appear in the helper class picker?
- Are the selectors using helper classes instead of section references (for example,
div[node_name=""]ordiv[data-node-id=""])?- If not, are there comments explaining why?
- Can the selectors' specificity be reduced and still work (for example, .layout > .layout-body > .flex.content.helper-class > .flex.content-item to .content.helper-class > .content-item)?
- If the overrides are intended for end-user portals, does the CSS file start with "py" so that it can be overridden by customers?
- Are all CSS warnings justified?
Skin
- Is the format using existing mixins as much as possible?
- Is the format sufficiently unique enough (meaning it can't be easily replaced with another format and/or helper classes)?
- Does the format conform to the design system?
- Does the format have the correct focus, hover, and active state styles?
- Does the format's name reflect its purpose rather than its style (for example, Case details card versus White square with padding)?
- Does the format's description explain when and where to use it?
JavaScript
- Is the script stored in its own JS file (that is, not contained in a non-auto-generated section)?
- Is the javascript being loaded properly?
- If meant to be a global script, is it attached to a top-level harness, or packaged as part of a bundle?
- If meant to be a local script to a particular section, is it being loaded with the <pega:onlyonce> directive (via a non-auto-generated section)?
- Is the script tag writing inline styles to the DOM (i.e. should it be adding/removing helper classes instead)?
- If so, are there comments explaining why?
- Is the script properly unbinding event handlers to avoid memory leaks?
Check your knowledge with the following interaction.
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?