One of the most important steps before launching an app is to test it for any stop-gaps. It can be a time-consuming process since each element of the app has to be thoroughly perused. To help you save a bit of time, we’ve compiled a short checklist of things you need to go through while reviewing your React JS code.
But what could be a few possible reasons for conducting a React JS code review? Here are a few:
- Bringing the other developers up to speed on any changes made in the project.
- Sharing some best practices or know-how with your team.
- Provide a bit of on the job training to less experienced developers.
- Try and figure out alternate solutions.
- Zero in on any existing or possible future issues.
To go with the reasons for conducting a React review, there are some mandatory pre-launch checks that you have to conduct on seemingly inconspicuous elements before every app launch. Things such as:
Let’s have a brief look at what each individual test entails to ensure that you don’t miss out on a crucial review.
- Is the code error-free?
- Does the project consist of a Readme file filled with instructions on how to run locally, along with other ancillary information?
- Is the app working as planned?
- Does the app look good on mobile devices?
- Is the codebase using eslint? If not, then why so?
- Ensuring that no dist files and editor/IDE files are checked in. There should be a .gitignore extension in place instead.
- Are there individual tests for crucial parts of the codebase?
- Make sure that you don’t conduct any unnecessary tests. For, eg. Avoid running tests on the Static Data and the framework.
- Do all file names have consistent casings and extensions?
- Do all the variables/functions/modules have consistent casings?
- Do all the variables/functions/modules have descriptive names?
Even though the above tests are important, the most important test is still testing your React JS code. Below are a few things that you must go through before finalizing the overall framework and giving your app the green light:
- Weed out any line of code with side effects from the final render.
- To reduce the risk of duplication, see if the code can be split up. Typically, React JS components should be small and based on the Single Responsibility Principle.
- Check if your props are de-structured, in case you’re using CS6.
- Try to use functional components for the components that don’t use State.
- Avoid mix-ins. Preferably use HOCs and compositions.
- Be sure that you don’t edit the props within a component, since they are ready only.
- In the render method, scale back on logic. Logic is better suited for components, helper methods, or redux actions (if you use them)
Conducting late-stage pre-launch checks can be daunting and exhausting in the best of circumstances. With launch deadlines and product specs mandates to take care of, testing can really be a hectic activity. On the flip side, it also allows you to go through everything you’ve done in the process of making your app, and avoid post-launch hiccups.
Even if you don’t solve all problems, you can always roll out consistent incremental updates or run community-driven beta tests to get direct feedback from the users on where they feel the app is letting up, and then work to fix the problem. Almost every major tech company does that today, so it may not be a bad option to explore.