Reacting to React!
TBH, React is kinda confusing. But isn’t all code a little confusing before you go through the late-night video lecture, the early morning study sessions, and the nagging, random thoughts of debugging solutions for the broken code from yesterday. I recently developed a React app that was modeled as an online art gallery in which users can write comments and rate the specific art pieces on the page. Like Leonidas, I went through many a trial and tribulation — I faced formidable foe after another in the form of “ERROR”. I climbed on the heights of mountains overlooking the vast army that stood in the path of where I wanted to go. I raised a shield to protect my heart from the stress and anxiety of broken code and raised a sword to debug the issue of a broken mind. The battle will always be won!
The biggest issue I found with React actually stemmed from foundational concepts that was confusing to me coming from a background of Rails and vanilla JavaScript which loosely followed MVC and Object-Oriented Programming. So, you can think of this as a sort of React 101 where I explain some foundational concepts in a way that I hope will help you overcome the battle I faced with grace and understanding.
Before I get into what React is, how to utilize it, and the entirety of that great stuff — I need to clarify that React isn’t “MVC”, React is a JavaScript Library for Building User Interfaces. It isn’t prepared out of the crate for you to take a cleaned web application right to the end goal. I consider React to be one basic piece of a bigger tech stack that permits you to definitively characterize your webpage. React then again is a completely unique creature. This comprises of a horde of integral libraries, ideas, and a thriving system that can feel pretty uncomfortable. LOL. But let’s dive in…
Components:
A component is basically a depiction of a piece of UI.
React is about components. Building an application with React involves making numerous of these components together to rejuvenate the application. Think Legos where parts are to a web application as Lego blocks are to a Lego palace.
Components are comprised of 2 essential ideas.
1. State: A component is an unadulterated capacity of state. State in, UI out.
2. Lifecycle: A component’s behavior is characterized by its lifecycle techniques.
Given a similar info (state), a component will consistently return a similar UI (render) something very similar. Behavior, for example, responding to state changes, performing activities when mounting/un-mounting to the DOM, starting a HTTP demand, diverting/inciting the client, and so on… is announced all through the part’s lifecycle techniques.
Stateless Function Components
So far, we realize that React parts are made out of state, props, and component lifecycle. Incidentally, most of your components can get by without one or the other state or component lifecycle, leaving you with just props. This permits you to characterize little, basic components as unadulterated elements of props to depict your UIs. No lifecycle snares. No state. Simply solitary info — props. These components should not hold an interior state, don’t have backing cases, and don’t have the part lifecycle techniques.
They are unadulterated useful changes of their contribution, with zero standards. In an ideal world, most of your components would be stateless capacities. These are the favored technique for characterizing parts and doing so will by and large prompt more proper use of state, less basic APIs, and a by and large a more joyful life :)
Class Components:
There are numerous situations when a Stateless Function Component just won't cut it. You should persevere utilization state, make utilization of the component lifecycle API, or quite a few things that the “streamlined” Stateless Function Components simply don’t uphold.
The most remarkable advantage to class components is the approach the component lifecycle techniques. These give a basic, yet incredible API that permits you to guide into different focuses in a component’s lifecycle to do things, for example,
• Initiate an Ajax approach componentDidMount
• Add and eliminate occasion audience members in componentDidMount and componentWillUnmount
• React to state change in componentWillReceiveProps or componentDidUpdate
• Optimize for execution inside shouldComponentUpdate
Props:
React components have an API worked in to announce and approve props. This is extraordinary during the improvement cycle as React assesses the props being passed to parts during runtime and gives accommodating alerts in the control center. A component’s props are basically its depiction of “on the off chance that you will utilize me, this is the thing that I need”.
JSX:
Try not to get too hung up on this new grammar, JSX. It might seem as though you are composing HTML within your part documents (you are not) or that it is some new templating language (it isn’t). Dread not! It is just grammatical sugar on top of the JavaScript work calls you know and love.
React’s docs likewise have an incredible JSX area where they clarify a portion of the how, what, and why behind JSX. Likewise, make certain to find out about how to deal with restrictive rationale in JSX as it, let me accentuation once more, isn’t a templating language.
One Way Data Flow:
Bid farewell to two-way information restricting and DOM questioning. React, information streams one way: from the top to the base. Guardians (components higher up in a component tree) pass down props to their kids. A few props can address “a piece of state” (read, for example, an amount in a shopping basket. Different props can be “capacities to refresh/influence state” (compose) like addition amount.
Like all coding, practice makes perfect and with the right foundation, the battle is yours to win! Always feel free to look at the React docs as well. I hope this helps you React pioneers!
