From what it is, to who uses it and how, here’s a little rundown of ReactJS/React.

Classic React instead of Hooks (pun intended) represented here. Photo by Antonio Batinić on Pexels.

If you’ve looked at web developer job listing recently, you’re probably familiar with the word React. It’s preeeety popular in development circles right now, and while the official site gives great info on the how of React, it might still be a little unclear as to what and why.

React is…?

…a framework/library extension of JavaScript. It was originally developed by Facebook for flexible (uh, reactive) changes to their newsfeed before going open source. It currently sits at the top of the mountain for industrial scale front end development.

Due to its popularity, React has very active, ongoing development, lots of code examples (although mostly class-based, more on that later), and many additional libraries that work with it, partially because of some of its limitations. React itself is mostly concerned with managing and rendering state to the DOM.

Wait, what do you mean by ‘state’?

‘State’ in this case refers to the current observable condition of your DOM. What variables currently are, what data is being rendered, what functions are at play… React seeks to flexibly govern how these change.

Vanilla JavaScript has some weaknesses in rendering changes, usually necessitating large components be refreshed, or even the whole page. React gives more power to update and re-render without having to make too many more server-side requests.

React uses components to scope the updates to state, and these components come in two different flavors: functional and class-based.

Oh, state-based, that was mentioned earlier. What is a functional vs class-based component?

Well, to put it unhelpfully but accurately, functional components operate more like traditional JavaScript functions, and class-based ones follow the pattern of classes in JavaScript.

You’re right, that was unhelpful. And I can’t say I’ve done much with classes in JavaScript…

You would not be alone there. But as originally conceived, class components in React were to do the work of handling state, whereas functional ones would be more used for, well, regular function things: computation, mutation, assignment, etc.

Here’s how a class-based one would look:

class ClassyComponent extends React.Component{
  render() {
    return <p>Yo, this is some wicked cool JSX.</p>
  }
}

And here’s a functional one:

const FunctionalComponent = (props) => {
  return <p>Greetings, {props.name}! I am a highly functional component.</p>
} 

Wait, what do you mean by, ‘originally’?

Well, things change. With React 16.8, hooks were introduced. These helper functions allow you to tap into state with functional components as long as you follow certain defined rules.

Because the methodology of writing functions is a lot more familiar to many developers, and certain aspects of class can be awkward and more verbose, functional components with hooks are increasingly the preferred choice for new React development. It is, however, relatively young in its lifecycle (slightly beyond the componentWillMount stage, maybe… sorry, that’s a joke), and you’ll find a lot more code examples out there that uses class-based components than functional ones.

So I can just ignore class-based ones completely?

Almost? There is still quite a lot of legacy code that uses classes, and sometimes it’s more trouble to convert than it’s worth. Still, it’s safe to say that whether you’re doing background computation or dynamically serving JSX, you would be better served to reach for functional components + hooks more often than not.

JSX… I think I may have heard of that before but… refresh my memory.

JSX is an abbreviation for JavaScript XML, which itself is short of eXtensible Markup Language (funny how acronyms work, innit?). And if the ‘markup language’ part sounds familiar, it’s not coincidence: JSX looks and acts a whole lot like HTML.

return (
    <div className="container">
      <h2>Your Weather:</h2>
      <input
        type="text"
        className="searchBox"
        autoFocus
        value={location}
        onChange={handleLocation}
        placeholder="Enter City"
      ></input>

      <label>
        <input
          type="radio"
          id="imperial"
          name="temp"
          defaultChecked={true}
          onClick={handleTemp}
          value="imperial"
        ></input>
        F°
      </label>

A simple input with labels inside a div, but dynamic values right in line.

JSX allows you to write components you want to render in your DOM much more naturally than pure JavaScript, where you might be stuck with having to go through the steps of creating, appending, and defining the attributes of elements line by line.

It does have some small lexical differences from HTML, like using className instead of class (which is natural, because they didn’t want things getting confused with class components) or instead of innerHTML, it has dangerouslySetInnerHTML which as the name implies is not generally recommended for use.

The main leg up JSX has on HTML is the ability to use variables and functions right in line with your static and divisional elements, including allowing you to share or ‘lift up’ the state of your component.

Ooo! That sounds important. What does it mean to ‘lift up state’?

This ones a bit tougher. Generally, lifting up state is a way of sharing state by “moving it up to the closest common ancestor of the components that need it” (React Docs). This makes it so that changing data can be reflected in other components.

To keep them in sync, you make the state more centralized to a single “Source of Truth” (should be read in a loud, echoey voice). Since React props are immutable, and the state is what you need to allow the app to update, you need to make that state available to a parent component so all children components keep in line. Sort of like having dad hold the remote control.

In practice with modern React hooks, lifting up state essentially amounts to having a parent functional component contain your subcomponents, and using the useState() hook to both keep track of the current state, and provide a function by which that state can be changed. This is in lieu a two-way binding you might see in other frameworks and languages.

export default function Weather() { //big momma functional comp
  const [location, setLocation] = useState("");
  const [tempSystem, setTempSystem] = useState("imperial");
  //subcomps that use/update state of location and tempSystem
  //lots more code....

So that it! Just a small breakdown of React Theory 101. There’s of course tons more at https://reactjs.org/, on YouTube, and StackOverflow. Good hunting!