So...what is React?

Good day and welcome! Thank you for tuning in, let's get right to it...

We just finished up with Phase-2 at Flatiron, rounding out our Front-End adventure with a jaunty sojourn to the land of React.

"React," you say? Why...what's THIS?

And better yet...why should we care? We already know how to use JavaScript, HTML, and CSS - isn't that everything there is to learn?

I mean, aren't ALL websites and applications written in an overly-complicated, nightmare-vortex of JavaScript-callback-Hell from which there is no escape?
Doesn't it take teams of programmers months and months to diagnose a resolve a few lines of buggy code?
Don't developers completely re-write their programs from the ground-up if they need to modify a few elements?
....WHY NOT?!

I hear you. And as logically sound as all of those arguments are, there is actually a reason to care. To put it simply, we use React because we love to RECYCLE!

From React's own website - reactjs.org, "React is a library for building composable user interfaces. It encourages the creation of reusable UI components which present data that changes over time."

So what does that mean for us humans that speak with human words? Well think of it this way; React combines the readability of HTML with the functionality of JavaScript.

HTML is great, but it's also super rigid and difficult to update if we need to. Pages aren't very interactive, and manipulating their layout is a pain.

One way to solve this issue is by rendering HTML elements using JavaScript and DOM manipulation, but...vanilla JavaScript sucks. It's hard to read, and everyone knows it. Vanilla JS has no friends. Like the person that invented the false X on ad windows in game apps.

But since JavaScript has been around for a while, a bunch of smarty-pants people have pretty much already written all the JavaScript rules and stuff that we could ever need to render HTML elements or manipulate the DOM...mostly. I mean, chances are if you need to do a thing in JavaScript, someone else has already figured out how to do that thing.

So why re-invent the wheel? Why not collect all of those JavaScript chunks together into some kind of massive library that we can access and use whenever we want?

That's more-or-less what React helps us to do (even though it's not a library per se, it's actually a framework 🙄). As developers, we use React to call on all those rules and stuff, and make a little hybrid franken-baby chunk of code that looks kiiiiinda like JS and kiiiiiiiinda like HTML.

React also allows us to trim our HTML to just a single file. Neat right? But wait, there's more! We can ALSO take all those persnickety little JavaScript functions and separate them out into their own little containers, where we can control their individual behavior. Then, we can pull all of those containers together into one big group - potentially using some of those containers more than once depending on their functionality - and it's that group of containers that collectively makes up our webpage.

We call these little containers components, which are basically files that hold JavaScript functions and return an HTML/JavaScript syntax mashup called JSX. From reactjs.org, "Components let you split the UI into independent, reusable pieces, and think about each piece in isolation.”

JSX Components combine the markup of HTML with the logic of JavaScript to define an aspect or group of elements within a specific chunk of the user interface on our webpage.

These Components all feed into one another in the same tree-like structure we’ve come to know so well. Much like literally everything else up to this point that we’ve covered, the internal structure resembles a tree, with the top of our dependency tree (typically an index.js file) importing each branched file. Developers. Love. Trees.

React uses index.js to render our components into our HTML file by using the .render method. We use document.getElementById("root") to identify a pre-existing div element in our HTML file with the id="root", and append our JSX components to it. When our program runs, React renders our JSX components as the Children to the Parent div.

The bare-bones structure of index.js looks like this:

import React from "react";
import ReactDOM from "react-dom";
import App from "./components/App";
import "./index.css";

ReactDOM.render(<App />, document.getElementById("root"));

The top-parent component is conventionally named "App.js" and is imported here with the line import App from "./components/App"; Here's an example App component:

import React from "react";
import ExampleComponent from "./ExampleComponent";
import OtherExampleComponent from "./OtherExampleComponent";

function App() {
  return (
    <div className="App">
      <h1>Welcome to React!</h1>
      <p>In React apps, we write JSX - 
it looks like HTML, and uses a lot of HTML syntax
...but it also looks like JavaScript, and uses a lot of JavaScript syntax...
</p>
      <ExampleComponent />
      <OtherExampleComponent />
      <OtherExampleComponent />
    </div>
  );
}

export default App;

Here, App is importing two children components of its own - ExampleComponent and OtherExampleComponent - and renders them as siblings to a p and an h1, all contained within a parent div. We even have OtherExampleComponent rendering twice! WHAAAAT?!

The internal structure of ExampleComponent and OtherExampleComponent is defined within their respective JSX functions, in separate individual files. At the bottom of our App component, we put export default App so that our index.js file is able to import it to use and ultimately render that App component.

This...is a lot. But the basic structure is a quasi-Russian-Doll-esque sort of functionality, where interconnected components can pass information and behavior back and forth as needed. For more on that, check out the React documentation on props.

In a nutshell, React helps us to simplify what's called the boilerplate code. In computer programming, boilerplate code, or simply boilerplate, are sections of code that are repeated in multiple places with little to no variation. When using languages that are considered verbose (overly wordy - cough JAVASCRIPT cough), the programmer must write a lot of boilerplate code to accomplish only minor functionality.

Until React comes along, takes one look at all that absurd boilerplate and dares to ask...

React helps us re-use things that have already been made, and saves us from having to make them ourselves the long way. In the land of the DRY code, the programmer with React is king.

-- ONE FINAL NOTE! --

If you're just starting out, I HIGHLY HIGHLY recommend these videos on Scrimba for learning the fundamentals.

Bob Ziroll is AWESOME and really takes the time to flesh out all the basics of React and how it behaves. Scrimba's videos are HANDS DOWN the best resource I found for learning introductory React stuff. Scrimba allows you to manipulate the instructor's JSX code directly in the video window, and even saves your edits as notes, which I found remarkably helpful for my comprehension.

And that's it - thanks so much for making it this far! If you have any questions or recommendations for edits, feel free to reach out. I welcome any and all feedback.

Keep fightin' the good fight! ʕ•ᴥ•ʔ