Hello brothers, it’s me again

Today, I stood up again to share with everyone a few things, this time some of my experiences with coding in the React project. We hope the article will be useful to everyone.

Do not know that while at work, have people ever encountered the following situations?

Too many props:

When we pass too many props to a single component it can be an indication that that component should be separated.

Then one more question arises: How much is too much ??? Yes, my answer is “Depending”. We may run into a situation where a Component is passed 20 props or more, when you encounter a situation like that and the task asks us to add another props, we’ll have to ask more questions.

Is this Component doing too many things ???

In my opinion, it’s like a function , a component should do the best of one task, so to do this, we should check if it can divide that component into many components or not? For example that component has incompatible props or it returns JSX from functions.

Should I only use a Component ???

Using only one Component is very good but what we often ignore is that all logic in that component is processed without splitting. I have an example as follows:

Looking at the above component, we can see that all functions are handled in that component, but we can still improve this confusion by breaking down the processed components in this component. :

Okk after processing, now I have ensured that ApplicationForm has only one job of it is to send and destroy the data fields in the form. Child components can handle anything related to their part in the form. This is also a great opportunity for us to practice using React Context for parent and child communication.

Are we passing too much ‘configuration’-props?

In some cases, we should group the props together into an optional object, in case we want to change an option. For example:

I think we should do the following:

Incompatible props

We should avoid passing inappropriate props:

For example, when we create a common <Input /> with the task of handling text in the form, but after that, we may want to process the input of number.

As we have seen, the problem with this common is that the props passed to isPhoneNumberInput and autoCapitalize don’t make a lot of sense. We can’t capitalize the phone number right.

In this case, the only solution is probably to split it into many smaller parts. If there is still some logic to share, we can turn it into a custom hook:

Copying props into state

Let’s see the following example:

Passing this props text means we have given up on the text value being updated because if it is updated the component will continue to render the state’s initial value, which will cause them to We are more prone to bugs.

A more realistic example of this happening is when we want to get some new value from a prop and especially if this requires some slow computation. In the example below, I will run the slowFormatText function to format the prop text, which will take a lot of time to execute.

A better way to solve this problem is to use the useMemo hook to remember the results:

Returning JSX from functions

We should not return a JSX from functions within a component.

For example :

Although this code looks ok, it makes it difficult for me to reason about the code and does not encourage people to write this way. To solve this case, we should break it down into separate components.

Remember, not every time you create a new component you move it to a new file. Sometimes it is advisable to keep components in the same file if they are tightly coupled together.

Multiple booleans for state

We should avoid using multiple booleans for state representations.

When writing code, sometimes we will come across situations where we need to check the state of that component to see what state it is in to perform the function:

In the above code, when the button is clicked, we will change the isLoading state to true and do the fetch request. If fetch success then we will change state isLoading to false, isFinish to true, and vice versa, set hasError to true if in fetch an error occurs.

Although the logic above can run well, it is very easy to confuse me, it can also fall into the case of ‘impossible state’, meaning that accidentally isFinish and isLoading both have true values ​​at the same time.

A better way to solve this problem is to use enum :

By doing it this way, we eliminate the impossible and make the logic a lot easier. If using TypeScript, it is better as follows: