You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For overview, do not summarize the changes. Only provide high level feedback on code quality, performance, and best practices.
2
+
3
+
When reviewing code, focus on:
4
+
5
+
## Performance Red Flags
6
+
7
+
- Spot inefficient loops and algorithmic issues
8
+
- Check for memory leaks and resource cleanup
9
+
10
+
## Code Quality Essentials
11
+
12
+
- Functions should be focused and appropriately sized
13
+
- Use clear, descriptive naming conventions
14
+
- Ensure proper error handling throughout
15
+
- Suggest changes to improve code readability and maintainability
16
+
17
+
## Best practices
18
+
19
+
- Refer to official documentation and best practices for React.js, Redux and Node.js. If you see anti-patterns, highlight them and provide links to the relevant official documentation.
20
+
- Encourage modern JavaScript/TypeScript features and syntax where applicable (e.g. for-of loops, nullish coalescing for Javascript; utility types or satisfied for Typescript..).
21
+
22
+
### Testing
23
+
24
+
- Follow the official testing guidelines for Redux and React Testing Library.
25
+
- Ensure tests are meaningful, maintainable, and cover edge cases.
26
+
- Avoid false positive tests.
27
+
28
+
### React
29
+
30
+
- Follow React patterns and naming conventions when designing components, “think in React”.
31
+
Be careful when using hooks, make sure that all dependencies are listed for callbacks / memos / effect.
32
+
- Keep in mind that defining non-primitive values in render (in function body or as component props) nullifies all memoization benefits.
33
+
- Same applies to non-primitive properties constructed inside Redux connect functions, they remove any benefits of granular connections
34
+
- Be especially careful when adding effects, remember that “you might not need an effect”.
35
+
- If you’re reaching for a useReducer hook, consider if it’s time to move this state and business logic to a Redux store instead.
36
+
37
+
### Redux
38
+
39
+
- The store state should be normalized, minimal, and based around the data you’re storing, not components.
40
+
- Keep in mind that not all state belongs in the redux store
41
+
- Be especially vigilant deciding whether something is state or a derived value produced from multiple existing sources
42
+
- As much state as possible should be calculated in reducers, reducers should own the state shape
43
+
- Store actions should be modeled around events, should not be dispatched in batches, and should handle all complex feature logic, especially the one requiring state and service access, instead of doing this in UI directly
44
+
45
+
## Review Style
46
+
47
+
- Be specific and actionable in feedback
48
+
- Explain the "why" behind recommendations
49
+
50
+
## MongoDB Specifics
51
+
52
+
### Performance antipatterns
53
+
54
+
- Warn about db.stats() performance implications, especially in connection with freeStorage: 1. Provide a reference to the official MongoDB documentation.
55
+
56
+
## Compass Specifics
57
+
58
+
- We're trying to stick to Redux style guide as close as possible, with two exceptions:
59
+
- Compass doesn’t use a single Redux store to manage the whole application state.
60
+
- Components inside the feature module boundaries don’t use Redux hooks API as a way to access data from stores (we do allow exposing hooks as public interfaces outside of module boundaries), using connect function instead.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4&size=40){kind=avatar}
0 commit comments