CodeLeap Pull Request Template

Pro tip: click the "Preview" tab above to understand WTF is going on, then edit accordingly.

What is this about?

PREFACE: In an effort to improve the teams’s efficiency and developer independence, we’re moving towards increased reliance in processes and methods to perform and review tasks.

⚠️ THE CODELEAP DEVELOPER BIBLE

Never commit to main/master in production projects, and avoid doing so in development unless there’s a good reason to do so. It is always best to get someone else’s feedback of your work before clients do. Check branching guidelines here.

Developers at CodeLeap should be independent and resolve issues by contacting peers, getting feedback from them and resolving product and technical issues.

It does not matter how or who resolves an issue. What matters is resolving the clients issues. Resourcefulness is as important as technical ability. Be resourceful and always aim to resolve the client’s issue as fast and efficiently as possible.

The reviewer is not a tester, and much less so are the clients. It is the assignee’s responsibility to make sure their implementations work on every platform, in any relevant scenario for the project. The reviewer's job is to proof read and ensure outstanding technical and usability quality.

Be mindful of collateral changes and think about the future. Good developers are only accurately identified after their code passes the test of time. Build things to be clear, avoid refactors in the future and avoid leaving technical debt behind.

Make sure your pull requests meet all the criteria in this PR checklist - making good shit is our top priority.

Please ask the team any questions that arise during development - you can never be too clear!

The review process

Start by choosing at least 2 reviewers for this pull request.

Make sure they’re familiar with the project and will have availability to review your work as soon as possible.

Once at least one reviewer has approved your work, you are welcome to go ahead and merge the code.

Make sure to communicate with the team.

If you’re a reviewer, make sure that…

• [ ] You are clear on what this PR is trying to achieve
• [ ] This task accomplishes the desired goal
• [ ] You read the diff and understand technical decisions
• [ ] The code in this PR follows this entire guideline

This Pull Request

Overview

What is this pull request about? Please add link to Notion issues here:

Ex. This adds whatever new feature...

Areas affected

Did this alter any screen other than obvious ones above?

Ex. The components changed are also used somewhere else...

Special Remarks

Anything special that the reviewer needs to know?

Ex. Some detail was kinda hacky, what do you think?...

Screenshots & videos

Please upload screenshots and/or videos of the areas changed

Best Practices Checklist

Make sure you follow these best coding practices:

• [ ] DRY - Don't Repeat Yourself
• [ ] KISS - Keep It Simple, Stupid
• [ ] Reuse existing code - check whether what you've done could be done by reusing or modifying similar components or functions
• [ ] Use variants wisely - check for best usage of existing variants or create new variants (when relevant); make sure variant sequences are not repeating themselves (DRY) or are redundant with styles object
• [ ] No arbitrary values - always use flex, Theme, variants or something intelligent and responsive to define styles
• [ ] Consistently bad is better than inconsistently good - make sure your code is similar to rest of the code
• [ ] Self documenting code - make sure your functions and variable names explain what they actually do
• [ ] Cleanup - leave consistent empty line spacing, remove logs, remove uneeded commented code, etc...
• [ ] Make linter happy
• [ ] Link this PR to its issue and update anything needed on the board

Project Checklist

Test your changes while:

• [ ] Logged out
• [ ] Logged in as a regular user
• [ ] Anything else?

Also make sure (strike out if not applicable):

• [ ] Images -> If you added/changed any image or icon, check:
  • [ ] Resolution is sufficient (at least 3x the size in UI points that's used in the code)
  • [ ] File type is adequate (png or svg for icons and interface details, jpg for large images)
  • [ ] It has the correct resizeMode
  • [ ] It has an adequate placeholder (if needed)
• [ ] Input -> If you added/changed an input field - check it has adequate:
  • [ ] Placeholders
  • [ ] Labels
  • [ ] “onSubmitEdit” handling
  • [ ] Keyboard type
  • [ ] Text data type
  • [ ] Keyboard avoidance
• [ ] List, grids, scrolls -> If you added/changed a list of items of any kind - check:
  • [ ] It scrolls and works correctly when having varying number of items (0, 1, 2, 3, 9+, etc...)
  • [ ] It has adequate pagination
  • [ ] It has adequate refresh control
  • [ ] It has adequate placeholders/empty component
  • [ ] It has adequate scroll indicators
• [ ] TabBar & Header -> If your changes add/change an app page, make sure it handles the tabbar and header information correctly
• [ ] Safe Areas -> Make sure your changes handle with the safe areas in the top and bottom of the page adequately
• [ ] Fetch, loading and AppStatus -> If you display any content fetched from the server, make sure we correctly handle a loading indication through local UI changes (spinner) or using AppStatus as needed. Also make sure the page renders correctly after refreshing (not coming from another screen)
• [ ] Placeholders & missing content -> Also when displaying fetched content of any kind, make sure to handle when there is no content by showing a placeholder or hiding the item. Check object properties that might not always exist and handle UI accordingly
• [ ] Formatting -> If you use any formattable data like numbers, currencies, date or time, make sure they're formatted in the best way for the users
• [ ] Dependencies -> If you add dependencies like packages, images or fonts, make sure they're all commited (including patch-package if relevant) and will work from a clean repo/yarn install on all platforms

Operating System Test Checklist

Test your changes on the following platforms:

• [ ] Android
• [ ] iOS

Dimensions Test Checklist

Make sure your changes look awesome near the breakpoints (check Theme) and on generally the following dimensions:

• [ ] Small (LG K3): 854x480
• [ ] Mid (LG K12 Plus): 1440x720
• [ ] Large (Iphone 12 Pro Max): 2778x1284
• [ ] I am sure this is not relevant for this PR

Final touches

Make sure you answer YES to all of the below:

• [ ] Get up, have a walk around for 5 minutes and come back here
• [ ] Take a look at your changes - is everything visually consistent with Figma and the rest of the app?
• [ ] Are all font sizes/weights and spacing/margins/padding consistent with this and other pages in the app?
• [ ] Does it all look and feel awesome?
• [ ] I am proud of what I've just submitted 🎉