React Pocket Guide Checklist
I keep meaning to write something more comprehensive about React, but the checklist format keeps coming back because it actually works when you are shipping code. The React Pocket Guide Checklist is basically a condensed reference you can keep open while debugging something that should not be this hard at 3pm. It breaks down into three bands: component structure, state management, and common pitfalls. Most people stop after component structure and never look at the other two, which is why their applications feel fine until they need to scale. The checklist itself lives as a single markdown file in most teams I work with. It is not official documentation, it is an internal artifact. If you search for "React Pocket Guide Checklist" you will find personal gist collections, GitHub repositories with slightly different versions, and occasional npm packages that try to package it. None of them are canonical. The closest thing to a real reference is the official React docs, which do not read like a checklist anyway.
I ran into a weird edge case last year where our linter kept flagging a custom hook as violating rules that the React Pocket Guide Checklist explicitly said were fine. The problem was our ESLint config was referencing an outdated version of eslint-plugin-react-hooks. Updating to the current major version fixed it in about four minutes, but the debugging took longer because the error message pointed at the hook implementation instead of the config.
How to use it without turning it into a religion
Start with the component section. List out the rules for props, default values, and prop types. Then move to state and effects, which is where most teams make mistakes. Keep the list short. Fifteen items max, or people stop reading it. I recommend keeping the checklist next to your component templates, not in the root directory where everyone ignores it. Most developers I know put it in a docs folder and forget about it until someone asks a question during code review.
Get the Full Details
State management and effects
This section of the checklist usually gets the most debate. The conservative approach says you should keep effects minimal and move complex logic into utilities. The aggressive approach says hooks should handle everything inline. Both are wrong for different reasons. The counter-intuitive part is that effects are easier to manage than you think if you restrict them to data fetching and subscription cleanup. When you start putting form validation or derived state inside useEffect, things get messy fast. I usually tell junior developers to keep effects below ten lines unless there is a very specific reason not to. Another pitfall: useMemo and useCallback. The React Pocket Guide Checklist mentions these, but it also implicitly warns against overusing them. Most developers add memoization before they have a performance problem. It does not help. The profiler exists for a reason. Use it before optimizing.
When the checklist fails you
There are scenarios where a static checklist cannot help. Context API combined with large component trees causes re-render issues that no amount of checking will catch. If your application is using React.memo incorrectly or context values that change on every render, the checklist becomes irrelevant. You need to look at the render profile instead. Server components and streaming SSR also break some of the assumptions in older versions of this checklist. If you are working on a Next.js project with the new architecture, the rules around client and server boundaries matter more than the component structure rules. Adapt accordingly.
A practical workaround
When the checklist feels incomplete, I extend it with a small section on debugging. Add a subsection for common errors like the "too many re-renders" loop, hydration mismatches, and stale closures. These are the problems that actually show up in production, not the theoretical edge cases. One specific trick: keep a running log of bugs alongside the checklist. When someone reports an issue, add it to the checklist if it is not already there. This keeps the document alive and relevant instead of letting it become stale documentation that nobody reads. The React Pocket Guide Checklist is not a substitute for reading the official docs or understanding how React actually renders. It is a reference. Use it as a sanity check before deploying, not as a replacement for thinking about what your code is doing.
If you want a copy, you can find versions scattered across GitHub. Search for react pocket guide checklist. Some teams maintain theirs privately. That is fine. The important part is that you have something concrete to check against when things break.
Final thoughts on maintenance
Keep it under twenty items. Update it quarterly. Remove anything that is no longer relevant. React changes fast enough that a checklist from two years ago might contain outdated patterns. The Hook rules changed a few times, for example. Version control the document and tag updates. I have seen teams treat the checklist like a law rather than a guide. That is the wrong mindset. It should speed up your workflow, not slow it down with debates over formatting. That is about it. Use it, tweak it, or ignore it. Just make sure you have checked your effects before shipping.
