├── License.md └── Readme.md /License.md: -------------------------------------------------------------------------------- 1 | CC0 1.0 Universal 2 | 3 | Statement of Purpose 4 | 5 | The laws of most jurisdictions throughout the world automatically confer 6 | exclusive Copyright and Related Rights (defined below) upon the creator and 7 | subsequent owner(s) (each and all, an "owner") of an original work of 8 | authorship and/or a database (each, a "Work"). 9 | 10 | Certain owners wish to permanently relinquish those rights to a Work for the 11 | purpose of contributing to a commons of creative, cultural and scientific 12 | works ("Commons") that the public can reliably and without fear of later 13 | claims of infringement build upon, modify, incorporate in other works, reuse 14 | and redistribute as freely as possible in any form whatsoever and for any 15 | purposes, including without limitation commercial purposes. These owners may 16 | contribute to the Commons to promote the ideal of a free culture and the 17 | further production of creative, cultural and scientific works, or to gain 18 | reputation or greater distribution for their Work in part through the use and 19 | efforts of others. 20 | 21 | For these and/or other purposes and motivations, and without any expectation 22 | of additional consideration or compensation, the person associating CC0 with a 23 | Work (the "Affirmer"), to the extent that he or she is an owner of Copyright 24 | and Related Rights in the Work, voluntarily elects to apply CC0 to the Work 25 | and publicly distribute the Work under its terms, with knowledge of his or her 26 | Copyright and Related Rights in the Work and the meaning and intended legal 27 | effect of CC0 on those rights. 28 | 29 | 1. Copyright and Related Rights. A Work made available under CC0 may be 30 | protected by copyright and related or neighboring rights ("Copyright and 31 | Related Rights"). Copyright and Related Rights include, but are not limited 32 | to, the following: 33 | 34 | i. the right to reproduce, adapt, distribute, perform, display, communicate, 35 | and translate a Work; 36 | 37 | ii. moral rights retained by the original author(s) and/or performer(s); 38 | 39 | iii. publicity and privacy rights pertaining to a person's image or likeness 40 | depicted in a Work; 41 | 42 | iv. rights protecting against unfair competition in regards to a Work, 43 | subject to the limitations in paragraph 4(a), below; 44 | 45 | v. rights protecting the extraction, dissemination, use and reuse of data in 46 | a Work; 47 | 48 | vi. database rights (such as those arising under Directive 96/9/EC of the 49 | European Parliament and of the Council of 11 March 1996 on the legal 50 | protection of databases, and under any national implementation thereof, 51 | including any amended or successor version of such directive); and 52 | 53 | vii. other similar, equivalent or corresponding rights throughout the world 54 | based on applicable law or treaty, and any national implementations thereof. 55 | 56 | 2. Waiver. To the greatest extent permitted by, but not in contravention of, 57 | applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and 58 | unconditionally waives, abandons, and surrenders all of Affirmer's Copyright 59 | and Related Rights and associated claims and causes of action, whether now 60 | known or unknown (including existing as well as future claims and causes of 61 | action), in the Work (i) in all territories worldwide, (ii) for the maximum 62 | duration provided by applicable law or treaty (including future time 63 | extensions), (iii) in any current or future medium and for any number of 64 | copies, and (iv) for any purpose whatsoever, including without limitation 65 | commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes 66 | the Waiver for the benefit of each member of the public at large and to the 67 | detriment of Affirmer's heirs and successors, fully intending that such Waiver 68 | shall not be subject to revocation, rescission, cancellation, termination, or 69 | any other legal or equitable action to disrupt the quiet enjoyment of the Work 70 | by the public as contemplated by Affirmer's express Statement of Purpose. 71 | 72 | 3. Public License Fallback. Should any part of the Waiver for any reason be 73 | judged legally invalid or ineffective under applicable law, then the Waiver 74 | shall be preserved to the maximum extent permitted taking into account 75 | Affirmer's express Statement of Purpose. In addition, to the extent the Waiver 76 | is so judged Affirmer hereby grants to each affected person a royalty-free, 77 | non transferable, non sublicensable, non exclusive, irrevocable and 78 | unconditional license to exercise Affirmer's Copyright and Related Rights in 79 | the Work (i) in all territories worldwide, (ii) for the maximum duration 80 | provided by applicable law or treaty (including future time extensions), (iii) 81 | in any current or future medium and for any number of copies, and (iv) for any 82 | purpose whatsoever, including without limitation commercial, advertising or 83 | promotional purposes (the "License"). The License shall be deemed effective as 84 | of the date CC0 was applied by Affirmer to the Work. Should any part of the 85 | License for any reason be judged legally invalid or ineffective under 86 | applicable law, such partial invalidity or ineffectiveness shall not 87 | invalidate the remainder of the License, and in such case Affirmer hereby 88 | affirms that he or she will not (i) exercise any of his or her remaining 89 | Copyright and Related Rights in the Work or (ii) assert any associated claims 90 | and causes of action with respect to the Work, in either case contrary to 91 | Affirmer's express Statement of Purpose. 92 | 93 | 4. Limitations and Disclaimers. 94 | 95 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 96 | surrendered, licensed or otherwise affected by this document. 97 | 98 | b. Affirmer offers the Work as-is and makes no representations or warranties 99 | of any kind concerning the Work, express, implied, statutory or otherwise, 100 | including without limitation warranties of title, merchantability, fitness 101 | for a particular purpose, non infringement, or the absence of latent or 102 | other defects, accuracy, or the present or absence of errors, whether or not 103 | discoverable, all to the greatest extent permissible under applicable law. 104 | 105 | c. Affirmer disclaims responsibility for clearing rights of other persons 106 | that may apply to the Work or any use thereof, including without limitation 107 | any person's Copyright and Related Rights in the Work. Further, Affirmer 108 | disclaims responsibility for obtaining any necessary consents, permissions 109 | or other rights required for any use of the Work. 110 | 111 | d. Affirmer understands and acknowledges that Creative Commons is not a 112 | party to this document and has no duty or obligation with respect to this 113 | CC0 or use of the Work. 114 | 115 | For more information, please see 116 | -------------------------------------------------------------------------------- /Readme.md: -------------------------------------------------------------------------------- 1 | # Frontend pull request checklist 2 | 3 | _Or how to get looks-good-to-me on your pull request seven times faster_ 4 | 5 | This is a generalized version of a checklist, I’ve created for my colleagues at Wayfair. Feel free to fork it and adapt to your team’s needs. 6 | 7 | [![Washing your code. A book on clean code for frontend developers](https://sapegin.me/images/washing-code-github.jpg)](https://sapegin.me/book/) 8 | 9 | ## Before you start 10 | 11 | 1. Setup your environment to have immediate feedback on your changes: 12 | 13 | - [Setup ESLint plugin](https://eslint.org/docs/user-guide/integrations) in your editor. 14 | - [Setup Prettier plugin](https://prettier.io/docs/en/editors.html) in your editor. 15 | - [Setup TypeScript](https://www.typescriptlang.org/index.html#download-links) or Flow in your editor. 16 | - [Setup stylelint](https://stylelint.io/user-guide/complementary-tools#editor-plugins) in your editor. 17 | 18 | 2. Read your team’s coding standards and style guides. 19 | 20 | ## JavaScript 21 | 22 | - JavaScript code is following team standards. 23 | 24 | ## HTML 25 | 26 | - All code is [WCAG Level AA](https://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixB.html) compliant. 27 | - _See [tools and techniques to use to test accessibility](https://daverupert.com/2018/07/assistive-technologies-i-test-with/)._ 28 | - Semantic tags are used where possible instead of `div`s and `span`s (headings, paragraphs, lists, etc.) 29 | - _See [Semantic HTML Tutorial](https://www.internetingishard.com/html-and-css/semantic-html/) for some examples._ 30 | - All interactive elements (links, buttons, form elements) are keyboard accessible and have visible focus states. 31 | - Tab order of all interactive elements follows a logical pattern, usually their position on the screen and order in the DOM. 32 | - All non-standard elements have appropriate ARIA roles. 33 | - All interactive elements have accessible labels. 34 | - _For example, add accessible text using the VisuallyHidden component or something similar._ 35 | - All non-text content has a text alternative. 36 | - _For example, images have appropriate alt texts, clickable icons have titles, and videos have captions._ 37 | - UI looks good on any screen size (mobile, desktop, etc.). 38 | - UI looks good with 200% page zoom. 39 | 40 | ## CSS 41 | 42 | - CSS code is following team standards. 43 | - No hardcoded colors, font sizes, whitespace, breakpoints and z-indices. 44 | - _Always use design tokens instead._ 45 | - No style overrides of any component library components. 46 | - No unnecessary CSS, ideally there’s no CSS at all. 47 | - _For example, prefer to use primitive and layout components instead of custom styles._ 48 | 49 | ## Tests 50 | 51 | - Add tests for new functionality. 52 | - _For example, add unit tests for tricky code and regression tests for bugs._ 53 | 54 | ## Documentation 55 | 56 | - Make sure that the documentation and comments are up to date after your changes, document any new APIs. 57 | 58 | ## Before sending code to review 59 | 60 | - Read the ticket one more time and make sure everything is done as requested. 61 | - Do a self review: carefully read all the code before opening a pull request. Think what kind of issues a reviewer may find in your code, what kind of questions they may have, what’s not clear. This alone can save you several review iterations and days in review. 62 | - _Having a coffee break or lunch before doing a self review could be a great idea to help you to look at your code with fresh eyes._ 63 | - _Take notes, mental of physical, on what kind of comments you get in code reviews — you’ll notice that they are often repeated. You can save lots of time by making sure you won’t get any of the comments that you often receive._ 64 | - _Hint: Use GUI Git clients for better experience like [GitHub Desktop](https://desktop.github.com/) or PhpStorm._ 65 | - No lint warnings, type errors or test failures. 66 | - _Hint: run these checks locally: `npm test`._ 67 | - _Hint: many warnings can be autofixed, check the documentation for your ESLint plugin._ 68 | - No new errors and warning in the browser console. 69 | - All code is formatted with Prettier. 70 | 71 | ## Pull request 72 | 73 | - Add screenshots or GIFs for any UI changes. This will help the person reviewing your code to understand what you’ve changed and how it works. 74 | - _Hint: use [Kap](https://getkap.co/) or [Licecap](https://www.cockos.com/licecap/) to record your screen._ 75 | - If your team uses a particular template for pull requests, fill it. Otherwise at least make sure you have: 76 | - the user problem you are solving; 77 | - acceptance criteria of the ticket; 78 | - testing you have done or plan to do before release; 79 | - any pull request that are dependent on this one, or any tickets on which this pull request depends. 80 | 81 | ## Code review 82 | 83 | - Ask to people to review your code: 84 | - a person who knows the domain well and can spot bugs in the business logic; 85 | - an expert in the technologies you’re using who can help you improve the code quality. 86 | - When you’re done with the changes after a code review, do another self review of the code and write a comment to notify the reviewer, that the pull request is ready for another iteration. 87 | - Review all the review comments and make sure they are all addressed before the next review iteration. 88 | - Make sure you don’t have similar issues anywhere else in your pull request. 89 | - If you’re not going to follow any of the code review recommendations, please add a comment explaining why. 90 | - Avoid writing comment like "done" of "fixed" on each code review comment. Reviewers assume you’ll do all suggested changes, unless you have a reason not to do some of them. 91 | - Sometimes it’s okay to postpone changes — in this case you’ll need to add a ticket number to the pull request and to the code itself. 92 | 93 | ## Asking help 94 | 95 | - It’s okay if you don’t understand some of the code review comments. Don’t hesitate to ask questions in the pull request, or ping the reviewer directly. 96 | 97 | ## Resources 98 | 99 | ### Code reviews 100 | 101 | - [How to get your code reviewed faster](https://blog.sapegin.me/all/faster-code-reviews) 102 | 103 | ### JavaScript 104 | 105 | - [JavaScript for impatient programmers](http://exploringjs.com/impatient-js/) 106 | - [Understanding ECMAScript 6](https://leanpub.com/understandinges6/) 107 | - [Washing your code: write once, read seven times](https://leanpub.com/washingcode/) 108 | 109 | ### React 110 | 111 | - [React docs](https://reactjs.org/docs/getting-started.html) (it’s one of the best resources) 112 | - [The Beginner’s Guide to React](https://egghead.io/courses/the-beginner-s-guide-to-react) 113 | - [Advanced React Component Patterns](https://egghead.io/courses/advanced-react-component-patterns) 114 | 115 | ### HTML 116 | 117 | - [Semantic HTML](https://internetingishard.com/html-and-css/semantic-html/) 118 | 119 | ### CSS 120 | 121 | - [How To Learn CSS](https://www.smashingmagazine.com/2019/01/how-to-learn-css/) 122 | 123 | ### Accessibility 124 | 125 | - [A Short Guide to Screen Reader Friendly Code](https://benrobertson.io/accessibility/screen-reader-friendly-code-guide) 126 | - [Accessible to all](https://web.dev/accessible) 127 | - [Accessibility Tips for Web Developers](https://dev.to/addyosmani/accessibility-tips-for-web-developers-4cn0) 128 | - [Assistive Technologies I Test With](https://daverupert.com/2018/07/assistive-technologies-i-test-with/) 129 | 130 | ### Testing 131 | 132 | - [Modern React testing, part 1: best practices](https://blog.sapegin.me/all/react-testing-1-best-practices/) 133 | - [What’s wrong with snapshot tests](https://blog.sapegin.me/all/snapshot-tests/) 134 | 135 | --- 136 | 137 | ## You may also like 138 | 139 | - [Jest cheat sheet](https://github.com/sapegin/jest-cheat-sheet) 140 | - [Opinionated list of React components](https://github.com/sapegin/react-components) 141 | 142 | ## Contributing 143 | 144 | Improvements are welcome! Open an issue or send a pull request. 145 | 146 | ## Author and license 147 | 148 | [Artem Sapegin](http://sapegin.me/), a frontend engineer at Stage+ and the creator of [React Styleguidist](https://react-styleguidist.js.org/). I also write about frontend at [my blog](https://blog.sapegin.me/). 149 | 150 | CC0 1.0 Universal license, see the included [License.md](/License.md) file. 151 | --------------------------------------------------------------------------------