Enterprise Frontend/React - Best Practices (DRAFT)
This document outlines best practices for writing/developing enterprise Frontend/React components, libraries, and applications at scale. Please make every attempt to follow these guidelines as closely as possible.
Outline best practices, guidelines, plugins, and tools that can be adopted, streamlined and integrated into React development for use across all platform teams
Understand what it would take to implement these guides and tools
Document and present guidelines to managers for approval.
Work with teams to implement those guidelines.
Improve product development, delivery, and iteration process
Provide consistent user experience
Improve application performance
Reduced developer onboarding time
Improved developer velocity to ensure product features are delivered Sprint
Improved code quality, reduction bugs and technical debt
Improved application performance, standards, and accessibility
Overview (Frontend Guidelines)
All applications, pages, components must have a consistent visual an functional user experience
Code function, format and structure should be consistent, no matter the number of contributors.
Always strive to maintain standards and best practices, but not at the expense of practicality. Use the least amount of markup with the fewest intricacies whenever possible.
Code should be easily understandable. complex code makes maintenance and debugging difficult and expensive.
Code reuse saves time, write reusable code follow the DRY (don’t repeat yourself) code principle whenever possible. DRY code is easy to maintain, refactor and manage.
Always follow recommended naming conventions attributes, classes, functions, filenames etc.
Always write semantic and compliant HTML5 markup; semantic markup including proper page landmarks (header, section, footer, main.)
Ensure the components, application and sites are accessible to all users by following
Use well documented/supported libraries or vanilla code where possible. Don't include unnecessary server-side code, libraries, frameworks, preprocessors, and other such dependencies — they can make the code less portable, and harder to run and understand.
When using external libraries please ensure that they are in active development, have strong developer community support, are well documented and provide a tangible benefit to the project
Please ensure that all imported libraries are updated and monitored for security vulnerabilities
Document your code whenever you can as it allows the team(s) to better understand code functions and usage.
Writing self-documenting code can help keep our codebase lite and readable—write descriptive classes, functions, variables names, etc. Use code comments sparingly and as an alternative to self-documenting code—this mix will help keep code clutter free while allowing other team members to better read, implement and support our codebase(s).
Reduce the use Html tables elements, table elements are not responsive, and it attached horizontal scrollbar on small devices, please use flexbox/css-grids whenever supported to reduce dependency on HTML tables
Variable names, HTML class names, HTML id names should be consistent across the project.
Refrain from creating ids to HTML elements when requirement is just to style HTML elements. Ids should be unique throughout the HTML page. So please check for the id-name if it is already assigned to some other HTML element.
Please refer to the following link(s) for a more detailed guide on HTML best practices
instead. (Note that only Dart Sass currently supports @use. Users of other implementations must use the @import rule instead.)
Don’t use @import for external css resources as it is slower, adds extra page requests, and can cause other unforeseen problems. Avoid them and instead opt for an alternate approach.
Place media queries as close to their relevant rule sets whenever possible. Don't bundle them all in a separate stylesheet or at the end of the document. Doing so only makes it easier for folks to miss them in the future.
The foundations of a solid CSS architecture can uphold the project as it begins to scale and grow. If these foundations have not been constructed properly, your project could likely fall over in the future.
React can change how you think about the designs you look at and the apps you build. Where once you might have seen a forest, after working with React, you will appreciate the individual trees. React makes it easier to think in design systems and UI states.
Start with a static mock of your component whenever possible as this helps us identify key features and gives structure to your application.
Break The UI Into A Component Hierarchy, identifying components, common elements and required functionality.
Use Functional Components instead of classes — Functional components are the stateless component that simply accepts data and display the output in some form, while Class components are stateful components that implement logic and state.
To make components reusable, break the larger component into smaller ones. That means instead of putting multiple functionalities in one component create one component that will be responsible for single functionality, the principle is called as “single responsibility principle”.
To minimize the component complexity it is always a good practice to isolate your stateful data-loading logic from the rendering stateless logic.
Avoid using Indexes as a Key Props According to React document, Key props help react to identify which item has been changed, added, or removed. Therefore, the key should be given to the element inside the array to give the elements a stable identity.
A properly maintained folder and file structure help you to understand project flow and simplify code maintenance and extraction to any other project.
Always follow naming conventions. Following naming conventions ensures users know how to name digital assets so that they will remain consistent and correct.
Testing ensures code integrity. Therefore it is good practice to create a Test directory within your component’s directory to perform all the required tests and ensure that the addition of new code will not break the existing functionality.
Have an understanding of Composition vs Inheritance in React and how it affects development.
Guidelines Deep Dive - React Development
TBA (Add guidelines for AEM best practices)
“Frontend Engineers work closely with the UX/UI, Development and Product teams to design, develop, and build optimized user EXPERIENCES for web applications.”
Work closely with the UX/UI, Development and Product teams to design, develop, and build optimized user EXPERIENCES for web applications.
Implement robust data visualizations and user interfaces that delight our customers
Write reliable, maintainable code by utilizing design patterns and refactoring techniques.
Craft performant high-quality features while ensuring quality through automated testing (unit, integration, e2e, and exploratory)
Ensure the product is accessible for all users by following WCAG 2.1 guidelines
Ensure that applications are responsive accross device
(Modern Frontend Engineering Roles)
Works closely with the UI/UX to create user interfaces that reflect the client’s requirements and the design team’s intent.
Focuses on function, interaction, reactivity, and usability of user interfaces
Data access, integration and management, auth, state, etc
Frontend Ops (operations)
Provides platform support for the team at all points of the development process
Works with build tools, VCS, deployment, automation, performance: (app, tests, builds, deploys), monitoring errors/logs, and Application stability
Streamlining and management of Frontend operations
Front End Specialist/Lead (hybrid)
Frontend Ops (operations)
Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it’s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts.
You should only commit code when it’s completed. This doesn’t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature’s implementation into logical chunks and remember to commit early and often. But don’t commit just to have something in the repository before leaving the office at the end of the day. If you’re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git’s “Stash” feature instead.
Resist the temptation to commit something that you “think” is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing / sharing your code with others
Begin your message with a short summary of your changes (up to 50 characters as a guideline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions: What was the motivation for the change? How does it differ from the previous implementation? Use the imperative, present tense („change“, not „changed“ or „changes“) to be consistent with generated messages from commands like git merge.
Having your files backed up on a remote server is a nice side effect of having a version control system. But you should not use your VCS like it was a backup system. When doing version control, you should pay attention to committing semantically (see “related changes”) – you shouldn’t just cram in files.
Branching is one of Git’s most powerful features – and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, ideas…
Follow your teams agreed workflow and branching strategy
Code reviews play an important role in the development process helping to reduce bugs, ensuring standards and improving the overall health of the codebase. Please ensure that code you thoroughly review pull requests (PR) ensuring code quality and before approving. Do not rubber-stamp PR approvals for any reason.
Using welcoming and inclusive language
Being respectful of differing viewpoints and experiences
Gracefully accepting constructive criticism
Focusing on what is best for the team/org
Showing empathy towards other team members
Technical facts and data overrule opinions and personal preferences.
Reference the code style-guide whenever possible to help developers improve the quality of code in a PR
Leave comments that help a developer learn something new. Sharing knowledge is part of improving the code health of a system over time.
Your link was not successfully embedded. Please try again with a different URL.
What is Web Accessibility?
Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with, or access to websites, by people with disabilities. When sites are correctly designed, developed and edited, all users have equal access to information and functionality. - Wikipedia
When you're building a modern web experience, it's important to measure, optimize, and monitor if you're to get fast and stay fast. Performance plays a significant role in the success of any online venture, as high performing sites engage and retain users better than poorly performing ones. Sites should focus on optimizing for user-centric happiness metrics.