DEV Community

loading...
Cover image for 10 Common React mistakes and problems beginners face

10 Common React mistakes and problems beginners face

devdefinitive
Just an average Hacker.
・5 min read

React is the most popular and best user interface framework in the technology world. Many large technology companies such as Facebook, Netflix, and Airbnb are responding. The demand for React developers continues to grow, and demand is high. Using React to build applications is the same as most front-end frameworks in the technical field. This learning path covers the basics of React, including common types, Firebase, Typescript, etc. Ultimately, you will master the skills to build great applications using React.

Let's talk about some mistakes developers tend to make


1-Not utilizing React and Redux dev tools

Applications consistently get carriage inevitably. Investigating is regularly a great deal of work, since more often than not a large number are included. With React dev tools, you can examine the delivered tree of React components, which is staggeringly valuable for perceiving how different parts develop a page.

The Redux dev apparatuses additionally accompany a large group of highlights that let you see each activity that has occurred, see the state changes these activities caused, and go back to before specific activities happened. You can add React dev tools as either a dev reliance or as a program expansion. Utilizing them will save you a ton of advancement time.

2-Utilizing class rather than className

While indicating the class name of the component in React, new learners use class rather than className and this gives them blunders. As class watchword is as of now held in JavaScript and JSX is only an expansion of JavaScript that is the reason React utilizes className rather than class.

3-Adjusting state straightforwardly

While changing a part's state, it's significant that you return another duplicate of the state with alterations, not adjust the present status straightforwardly. On the off chance that you inaccurately adjust a part's state, React's diffing calculation will not catch the change, and your segment will not refresh as expected.

4-Not composing unit tests

This is perhaps the most well-known errors out there. It's regularly ignored in light of the fact that applications can in any case actually work without unit tests. A unit test permits you to test portions of your application autonomously to guarantee a specific usefulness functions true to form. For example, you can compose a unit test to check if a prop passed to a segment was delivered on the program.

You may ask for what reason you'd compose a little test. In some cases you anticipate that your prop should show appropriately in the wake of composing your segments, yet sporadically a clashing CSS style may obstruct it from showing. Composing a unit test saves you the time you'd spend finding that bug by bringing up it promptly. They assist you with troubleshooting your application.

5-Utilizing Redux or Flux to deal with all your application states

In greater React applications, a ton of designers utilize Redux or Flux to oversee worldwide state. This is helpful, particularly when different pieces of the application will profit by having a common state. Nonetheless, it's unwise to utilize Redux or Flux to deal with each state in your application.

Take, for instance, a structure component. In the event that we need the condition of a check to consistently be checked at whatever point we visit it, the best methodology is to oversee it utilizing nearby state technique or useState (for Hooks) as opposed to utilizing Redux or Flux.

6-Not Capitalizing Component Name

The name of each React part should start with a capital letter in any case assuming we utilized that segment, the program will regard that segment as an implicit component like range or div, and you may get the admonition. To avoid this kind of warning, always start the React component name with the upper case letter.

7- Failing to remember that setState is nonconcurrent or asynchronous

It's not difficult to fail to remember that the state in React is nonconcurrent. It's something that even the most prepared React engineers neglect. Being nonconcurrent implies that any adjustments you make don't produce results promptly (and may produce results on the following render). Respond naturally bunches update calls to improve execution. In the event that you access a state esteem just subsequent to setting it, you probably won't get the most exact outcome.

8-A lot of re-rendering

This is principally an outcome of not sticking to configuration designs. I have seen commonly were props are set on a parent segment, like <Main/> and afterward passed right down to segments like <UserListSys/>, <UserLists/>, <User/>, <UserImg/>, and such. For this situation it is acceptable that such a page is separated into unmistakable parts, yet the issue is on the off chance that anything changes in any client, it will cause possibly many segments to re-render simultaneously, and the vast majority of them unncessarily.

Preferably, props ought to just be passed 2 levels profound, from parent - > youngster. This causes less re-delivering, and thinking in this way leaves your application significantly more decoupled and simpler to scale. At most as I would see it, props ought to be passed 3 levels profound. After that it turns into a torment to oversee/investigate code.

9-Going fast

There isn't anything amiss with requiring an entire week (or more) to get familiar with another coding language. This isn't actually discussed in the React people group. It's kind of expected that you by one way or another think about Webpack/Babel/ES6/single direction restricting, and so forth This can get overpowering actually rapidly, and you may lose revenue in learning React on account of the wreck that the JavaScript scene is right now in.

This is particularly the situation if your first undertaking incorporates a type of state the executives library like Redux, Flux or Vue. The most ideal approach to cure this is to just require significant investment and work out your insight in little advances. Find out about props, youngsters and segment state prior to stressing over the distinction among utilitarian and savvy segments. Try not to stress over single direction information restricting until you have a strong comprehension of simply passing down props from parent to youngsters. Adhere to the essentials for the clench hand not many days at any rate.

10-Thinking import/export Will Work

The import/export out include is an authority highlight in JavaScript. Nonetheless, it's the solitary ES2015 highlight that isn't yet completely upheld in current programs and the most recent Node.

The well known design of a React project utilizes Webpack and Babel. Both permit the utilization of this component and assemble it down to something everything programs can comprehend. You can just utilize import/send out on the off chance that you have something like Webpack or Babel in your stream.


Above are the some common mistakes and problems you probably had experienced when using React. Hope you like the article and has helped you in pointing your mistakes out.

Discussion (9)

Collapse
mkimont profile image
Matt Kimek

Number 0
Don't use react if you can do it in plain java script

Collapse
jazzbrown1 profile image
Jazz Brown

Well no.. a competent developer could make more or less anything in vanilla that could be done in react....

React reduces effort and complexity and just because you could delve into that complexity and increase the effort does not mean you necessarily should and in a lot of cases probably shouldn't.

I think it would be better to say don't use react unless there is value in doing so and that value does not have a significant cost (performance etc)

Collapse
mkimont profile image
Matt Kimek • Edited

Read ex. this stackoverflow.com/questions/582242...

Competent developer hate react, why - > check google

React is for multimillion corporations to save cost on servers.

If you don't know how to optimize it, how to scale your infrastructure, don't use it. Yes you can use it in startups but much easier would be to serve 'prototype' on static html on openlitespeed server plus some with vanilla js and api feeded json = easy and fast to do, easy to maintain, easy to extend. React won't solve your problem "till you master it" and still maintain that is a pain too (check previous paragraph about googling).

Advice for beginner: learn what exactly react solves and can you avoid it (it's easy to make state managers in vanilla js in few lines)

And last url probably the most important : medium.com/dev-channel/a-netflix-w...

I hope that you manage to notice: "server side react"

Thread Thread
jazzbrown1 profile image
Jazz Brown

'Competent developer hate react, why - > check google

React is for multimillion corporations to save cost on servers.'

πŸ™„πŸ™„πŸ™„

I don't need to Google it I work with plenty of competent developers that do not hate react and understand its value.

Hmmm.. strange.. react themselves seem to think they developed it for quite a different reason...

'React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes.

Declarative views make your code more predictable and easier to debug.'

Thread Thread
mkimont profile image
Matt Kimek
  1. "React was created by Jordan Walke, a software engineer at Facebook" <- 83.5 billion (2012 before React was created)
  2. Why they create that :
    You copy paste:
    "Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes"
    I read:
    You send less data to client, smaller chunks -> save money on each request.
    Does "React bundles a certain amount of overhead code, which will run in the browser’s JS engine" -> yes.
    Does company using your PC to generate/calculate stuff and save resources on they own servers this way -> yes
    Can you do simple UI just with plain json and js -> yes.

  3. Feeling towards React
    I work with Angular, Backbone+Marionette, Ember, Vue and React and in 90-99% scenarios this could be replaced by simple JSON and plain JS ( people don't understand "the real js and browsers" -> yes you can be competent React dev but not competent web developer )

Is it ease for your competent react developers to jump from recent React to React 4 and change stuff ?
I know that is not, is pain to do anything, even small changes are impossible, you cannot easily update anything and you are stuck.

Good code should be 'self-maintain' after years, should be easy to: read, update, port to different system/framework et cetera.

As new React is OK, plain js is also OK - you can do:
"Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes" in plain JS now.

Your competent react devs writing code, they feel that they doing good job 'following react way', after 2 or 3 years I need to tide up that crap and figure out what the artisans/competent react dev had in their head 3 years ago (why react was used for 3 json calls from time to time etc).

Good luck

Thread Thread
jazzbrown1 profile image
Jazz Brown

I think you are missing a whole lot of points here. Let's agree to disagree.

I can't help it if they write one thing and you choose to read something completely different......

This is a (very good) article for beginners and your mostly negative, ill informed ,obviously bias, comments are not helping anyone.

If you hate react so much don't read react articles jeeez

Thread Thread
mkimont profile image
Matt Kimek

I think you miss the point. As beginner learn java script first, stop writing everything in react when you can write it in javascript, learn language first (can you do it in js), learn tool, apply tool accordingly.

Everywhere I go this is the React beginner mistake number 1. = using react when you don't need it.

Ps
I am not fun of any frameworks neither language. You as dev are problem solver, you should write as less code as possible and ideally no code at all as I've seen scenario like that ex. Using throttling on php instead of server side.

Thread Thread
jazzbrown1 profile image
Jazz Brown

I agree with all of that.

But back to the original point for a beginner deciding when to use a tool 'dont use react if you can do it in plain js' is just too simplistic. And using react or any other library or framework should be decided based on a number of factors which will vary depending on the project goals. And in the commercial space, I'm afraid the most important will often be output/effort/time/complexity which react can greatly reduce.

I don't think that we are on totally different pages. If nothing else this thread at least shows new developers that it is important to take time to decide what toolsets you should be using for a particular project.

Good day to you!

PS tbh I am a fan of lots of languages and frameworks, I try not to let my biases sway my decisions though 😁

Collapse
mnemanja profile image
Nemanja Milosavljevic

Perhaps it would make more sense to say: "Don't use a library if you can write it yourself", but that was not a point here, I believe.