Writing clean React code, tips for Context API, and automation testing for React JS
by Seven Peaks on Sep 10, 2021 10:18:00 AM
On August 18th 2021, Seven Peaks Software held an online webinar to discuss more on React JS Development. This topic was named Deploying React apps with confidence. Our three speakers of React JS experts shared their knowledge & expertise on how to build, test, and deploy React applications with full confidence through writing clean React code with clean-code structure, tips for react context API class component, end to end tests with the cypress testing framework, and much more!
Writing clean React code
Denis Pshenov opened this virtual webinar by presenting on his topic of: Getting hooked on the performance in clean code, with his bold statement on running clean-code as: “By running clean code, one can achieve good performance”.
“So what really is a clean code? It’s the code that is easy to extend and easy to understand. In the case of a new member that comes into the team who is unfamiliar with the codebase will be able to come in and quickly contribute to the codebase, implement new features and all the other stuff.
To implement clean code it can start with clean naming, consistency, single responsibilities, and Finding the best practices for your topic and applying them.
Fast initial render
This could be done by three actions:
- Code Splitting
- Tree Shaking
- Lazy Loading
Fast response to interactions
This could be done by two actions:
- Fast Render Functions
- Re-render only when needed
React Is fast like actually fast where 90% of the time the user doesn’t need to be worried but, there might be a time when react becomes slow. When it becomes slow, one needs to understand where it is this slow and measure how slow it is. There are few tools that can help one to diagnose and measure on the problems:
- Flame Graphs
- React Dev Tools
- React Profiler
So once you identify you have a problem on a page but don’t know why the problem is there, what did i do wrong, and etc, to answer all your questions one really needs to understand why does react re-render something?
- React re-render components when state inside of it has changed
- React re-render when parents of that components has re-rendered
When there’s a component getting re-rendered, react will go to every child of that component and re-render the child and then go into chip child of their components, all the children and and re-render all the children.
So if we re-render from the very top of the react tree it will affect all the components down to the last node and it will bring a big effect on the performance. So you might want to optimize for the re-render at the very top so that it doesn’t need to re-render from the top very often.”
Sometimes you need to actually share the state between different components, well you need a global state. For a proper global state management, you can find a lot of NPM Libraries such:
- Context API
- Zustand (Maintained by Dashi Kato)
- Jotai (or Recoil)
- Use Context Selector
And there are still few other ways on the optimizations that can be done but are not based on the clean code practice:
React Context API
Our second speaker, Huad, started his talk by diving deep into context API through showing the latest tips, tricks, and the Do’s and Don’ts of context API so that you can make the most effective use out of it.
“Context provides a way to pass data through the component tree without having to pass props down manually at every level.”
“Another way allowing you to implicitly share data (state) between components.”
– Huad himself
Huad defines context as another way that allows you to implicitly share data (state) between components. As context is for state or data sharing, fundamentally in react , data sharing is just passing prop.
“So what’s the real problem and why do you need context when you can just simply pass prop? Well, the problem will arise when you pass down multiple levels.
It’s called props drilling. It happens when you have to pass down your data or prop into multiple levels, and the intermediate component doesn’t have to know about this data. Which is troublesome and annoying for some people.
So the problem caused by props drilling could be solved by the context API. The first thing we import is a function called create context from react. And it takes only one parameter, which is the default value that we just put undefined , or if you use TypeScript you have to pass this.
So, in the result of calling create context you get the context object instance, and then in the instant property you add a component called provider. So, you just need to create the component with the one required prop, which is value, this value we’ll be using when you consume the context.
You just create a component and wrap it. Everything inside. So when consuming the context. You just use another hook from react, called use context, and pass the context, instead.
In return, it gives you the value that you just passed in the provider before, which is the object that contains the current color and sip color.”
Testing Pyramid: Cypress testing framework, React testing library, and more
Our last speaker, Georgii, walked us through how to deploy your React Applications with confidence by performing practical testing, through using the Testing Pyramid, with the React Testing Library and Cypress.
Georgii starts off by explaining what you’ll need to expect when making a release to then delivering an application:
- New features work as expected
- There are no bugs
- There is no regression
“So why we should write test in our front end application:
- Clients hates bugs in their final product
- Refactoring, especially in the big part of the code is is painful as you might be worry that you will break something
- Regressions in the product that are already in production can have very high costs
- It is to save money and time
The basic concept of the testing could be in the form of testing pyramid
- 1st Level is unit tests
- 2nd Level are integration tests
- 3rd level is end testing
This concept or methodology can easily apply for the backend. On the unit tests, basically if you do, especially TDD, it’s much more like you write a unit test before you write into code.
Integration test you write a little bit less, but you just check how, let’s say API works just call API, and see, is it responding correctly, an endpoint, it’s mostly like postman or something like this you call rail API and see with real data, what’s going on.
But in the backend, you see failure right away, end to end tests, but each type of test has its own benefits.
Moving on to the testing trophy, Georgii starts with the basement of the concept which is static checks continued by unit tests, integration tests and end to end tests.
So what tools can be used on each test?
- Static Checks – Typescript, EsLint, Flow
- Unit Tests – Jest
- Integration Tests – Jest + React testing library
- End to End Tests – Cypress”
“Write tests. Not too many. Mostly integration.”
– Guillermo Rauch